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FOREWORD 

A Project  Implementation  Plan  (PIP)  which  describes  a 
plan  for  the  development  and  implementation  of  the 
Interactive  Financial  Management  System  (IFMS)  was  published 
in  February  1974.  The  PIP  proposes  that  an  interactive 
integrated  computer  system  be  developed  in  three  phases  to 
upgrade  the  system's  support  to  the  Lyndon  B.  Johnson  Space 
Center  (JSC)  Financial  Management  Division  (FMD) . IFMS  will 
satisfy  FMD  requirements  by:  generating  a new  online 
accounting  system,  enhancing  several  existing  batch  computer 
systems  supporting  FMD,  and  automating  several  functions  now 
being  accomplished  manually.  Phase  1 will  provide  for 
online  fund  control,  subauthorization  accounting,  and 
accounts  receivable  functional  capabilities.  Phase  1 will 
also  replace  the  existing  Basic  Accounting  System  (BAS); 
consequently.  Phase  1 will  also  include  all  the  existing  BAS 
functions.  Phase  2 will  be  an  extension  of  Phase  1, 
providing  FMD  with  the  Seneral  Ledger,  Disbursing,  and 
Property  subsystems.  Phase  3 will  be  concerned  with  the 
efficient  integration  of  the  existing  interfacing  computer 
systems  with  IFMS. 


This  Detailed  Requirements  Document  (DRD)  describes  the 
detailed  requirements  for  Phase  1 of  IFMS.  Phases  2 and  3 
detailed  requirements  will  be  integrated  into  this  DRD  after 
the  Phases  2 and  3 requirements  collection  and  analysis  have 
been  completed. 
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1.0  INTRODUCTION 


1.1  IDENTIFICATION 

The  Detailed  Requirements  Document  (DRD)  for  Phase  1 of 
the  Interactive  Financial  Management  System  (IFMS)  is 
written  in  response  to  job  order  84-357.  The  responsible 
NASA  organization  is  the  Institutional  Data  Systems  Division 
(IDSD)  of  the  Data  Systems  and  Analysis  Directorate.  The 
project  number  2572  is  assigned  to  this  system. 


1.2  BACKGROUND 

IFMS  is  being  developed  to  satisfy  both  the  existing 
and  new  systems'  requirements  of  the  Financial  Management 
Division  (FMD)  of  the  Administration  and  Program  Support 
Directorate.  The  FMD  operation  consists  of  a series  of 
highly  regulated,  complex,  and  integrated  operating 
procedures  and  processes.  These  operations  have  become  more 
difficult  to  maintain,  improve,  and  expand  as  increasing 
accounting  and  financial  reporting  requirements  have  been 
levied  on  FMD.  This  additional  workload  and  the  lack  of 
improved  and  more  comprehensive  data  processing  support  has 
resulted  in  FMD  being  unable  to  perform  its  JSC 
accounting/financial  management  functions  as  efficiently  and 
effectively  as  desired.  In  addition,  many  of  the  computer 
systems  currently  supporting  FMD  are  characterized  by  their 
inefficient  design  and  continuing  need  for  modifications  to 
accommodate  changing  requirements. 
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r Project  Implementation  Plan  (PIP)  foe  IFMS  was 
published  in  February  1974  describing  the  existing  FMD 
operation  and  computer  support,  IFMS  concept,  and  a plan  for 
IFMS  implementation. 

IFMS*  s primary  objective  is  the  implementation  of  an 
efficient,  flexible,  and  comprehensive  financial  management 
system  that  will  ultimately  integrate  FMD  operational  and 
computer  support  activities.  It  will  replace  the  Basic 
accounting  System  (BAS)  in  Phase  1.  The  interfacing  systems 
are  Labor  Distribution,  Institutional  Management  Accounting 
System  Phase  A and  Phase  B (IMAS-A  and  IMAS-B) , Service 
Center  Distribution  (SCD) , PR/497,  Supply,  Payroll,  Contract 
Status  and  Reporting,  Resource  Control,  Medical  Operations, 
Financial  and  Contractual  Status  (FACS) , and  Program 
Operating  Plan  (POP)  . 

1.3  SYSTEM  DESCRIPTION 

* 

IFMS  must  support  all  functional  activities  of  FMD.  It 
must  provide  timely  and  accurate  accounting  data  to  support 
| the  total  FMD  operation,  as  well  as  to  provide  current  and 

meaningful  financial  management  information  to  the  various 
levels  of  JSC  management.  IFMS  must  also  satisfy  all 
external  JSC  financial  reporting  requirements  and  adhere  to 
NASfi  Headquarters  and  the  Government  Accounting  Office  legal 
and  procedural  accountability  restrictions* 

' j . . ' . ' ' 

To  meet  FMD  functional  requirements,  IFMS  must  provide 

for  the  quick  and  efficient  entry  of  accounting  data  by  FMD 
personnel,  followed  by  a comprehensive  and  automated  edit, 
validation,  update,  and  report  cycle.  IFMS  will  be 
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primarily  online  oriented  with  the  daily  accounting  activity 
input,  edited,  and  processed  online.  The  online  inquiry 
capability  will  be  provided.  Batch  processing  will  be  used 
to  produce  recurring  reports  and  to  process  the  files  used 
in  the  interfaces  with  other  FMD  and  JSC  computer  systems. 
Each  of  these  areas  will  be  addressed  separately  in 
subsequent  paragraphs,  and  defined  specifically  in  section 
2.0.  The  general  system  concept  is  illustrated  in  figure 
1.3-1. 


1.3.1  IFMS  Input 


To  SFter  data  into  IFMS,  FMD  will  have  14  CRT  terminals 
located  strategically  at  various  FMD  locations  at  JSC.  In 


phase  1,  the  Institutional 

Resources 

Division 

(IRD)  will 

have  1 CRT  terminal  to  be  used 

for  IFMS  inquiry 

purposes 

only.  The  locations  of  the  cathode-ray 

tube  (CRT) 

terminals 

and  printers  are  as  follows: 

CRT's 

with 

Remote 

Building 

Organization 

printers 

printers 

location 

Fund  Control  Unit 

3 

419 

Central  Resources  Section 

1 

4 5 

Commercial  Accounts  Section 

4 

416 

Travel  Unit 

3 

1 

Cost  Accounting  Section 

1 

45 

Financial  Information  Center 

2 

1 

416/45 

Institutional  Resources 

Division 

-1- 

— 

1 

Total 

15 

1 
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The  precise  CRT  terminal  model  to  be  utilized  has  not  yet 
been  determined;  however,  its  required  characteristics  were 
enumerated  in  the  IFMS  PIP. 

Each  FMD  organization  to  enter  data  into  IFMS  will 
first  sign  on,  then,  request  the  appropriate  input  template. 
The  sign-on  will  require,  at  a minimum,  a user  ID  and  an 
access  code  to  facilitate  the  IFMS  authorization  and 
user/transaction  level  of  security.  The  template  called  by 
the  user  will  be  one  of  a series  of  templates  which  have 
been  standardized  and  generalized  to  support  a class  of 
financial  activity,  i.e..  Resources  Authority, 

Disbursements,  etc.  The  input  template  design  philosophy  is 
concerned  with  the  recording  of  an  activity  rather  than  the 
existing  system’s  mode  of  recording  input  transaction  and 
skip  codes  and  multiple  transactions  for  one  activity.  IFMS 
permits  the  user  to  indicate  the  activity  to  be  accomplished 
rather  than  requiring  the  user  to  know  the  effect  of  each 
transaction  on  the  data  base  as  in  the  current  system.  When 
the  template  has  been  requested,  a series  of  fill-in-the- 
blanks  will  appear  on  the  screen.  After  the  user  inputs  the 
necessary  data  elements,  IFMS  must  perform  field  edits,  edit 
table  validations/conversions,  and  processing  edits 
(requiring  data  base  access)  to  validate  the  input  activity. 
If  there  is  an  error,  the  user  will  be  notified  immediately. 
If  no  error  occurs,  the  proper  records  are  updated  within 
the  IFMS  data  base,  and  the  user  is  notified  that  the 
activity  has  been  accepted  and  processed.  On  the  following 
work  day,  the  user  receives  a list  of  all  valid  transactions 
processed  for  the  day.  This  list  is  to  be  used  primarily 
for  input  validation,  but  can  be  used  for  a transaction 
history  and  for  audit  trail  purposes. 
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1.3.2  IFMS  Inquiries 

The  inquiry  requirements  for  IFMS  can  be  placed  into 
two  categories.  First,  many  recurring,  predefined  inquiries 
have  been  identified  as  necessary  in  the  day-to-day 
operations  of  FMD.  These  inquiries  are  identified  in  this 
document  and  will  be  designed  for  rapid  user  input  (in 
effect,  "canned"  for  the  user’s  needs).  Second,  there  are 
other  inquiries  that  cannot  be  predefined  or  they  are 
infrequently  used.  These  inquiries  are  defined  as  ad  hoc 
inquiries. 

The  precise  input  and  output  formats  of  the  inquiries 
have  not  yet  been  determined  because  the  communication 
management  system  (CMS)  to  be  used  by  IFMS  has  not  yet  been 
determined,  and  the  data  management  system  (DMS)  inquiry 
features  have  not  be^n  sufficiently  evaluated.  The  inquiry 
format  designs  will  be  developed  during  Phase  1 functional 
design  activity.  Each  process  in  section  2.0  will,  however, 
specify  the  input  data  elements  required  for  each  predefined 
inquiry  and  the  data  elements  to  be  included  in  the 
response. 

1.3.2. 1 Predefined  inquiries.  Each  process  in  section 
2.0  identifies  the  predefined  inquiries  applicable  to  that 
process  and  specifies  the  required  input  data  elements  and 
the  data  elements  to  be  included  in  the  response  to  the 
inquiry.  Each  inquiry  specifies  the  type  of  data  required 
for  the  inquiry  (item,  list,  and  summary) . An  item  inquiry 
requests  access  to  and  output  of  a specified  basic  element 
set  defined  in  the  data  base  (e.g.,  what  are  the  commitment, 
obligation,  cost,  and  disbursement  amounts  for  a specific 
purchase  request  (PR)).  A list  inquiry  requests  access  to 
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and  output  of  a number  of  items  (e.g. r "hat  are  the 

receipts,  issues,  and  balance  by  Primary  Work  Code  (PWC)  of 
all  Research  and  Development  (R&D)  Resources  Authority 

(RA*s)  for  program  year  *74).  A summary  inquiry  requests 
access  to  many  items  but  requires  the  output  of  a total  of 
all  items  (e.g.,  what  is  the  total  receipts,  issues,  and 

balance  of  all  direct  t&D  RA's  for  program  year  *74).  In 

addition,  each  inquiry  specifies  the  response  time 

requirements  according  to  one  of  the  following  three 

categories: 

• Immediate  response  - The  immediate  response  inquiry 
will  be  entered  via  the  CRT,  and  a response  should 
be  returned  immediately  to  the  screen.  Item 
inquiries  and  certain  list  and  summary  inquiries  are 
immediate  response  inquiries.  However,  some  list 
inquiries  will  be  of  sufficient  length  (lines  of 
output)  to  require  the  output  to  be  directed  to  the 
remote  printer.  The  user  will  be  notified  at  the 
terminal  that  such  action  has  taken  place.  All 
immediate  response  requirements  have  been  designed 
to  meet  the  specific  daily  operational  needs  of  FMD. 

• Same  day  response  - The  remote  batch  inquiry  is 
designed  to  support  some  of  the  operational  and 
management  information  aspects  of  the  FMD  operation. 
The  responses  to  these  inquiries  will  be  directed  to 
the  FMD  remote  printer  and  should  be  received  the 
same  day.  This  class  of  inquiry  will  normally  be  of 
the  summary  or  list  level  of  detail. 

• overnight  response  - The  overnight  response  class  of 
inquiry  is  designed  to  satisfy  the  management 
information  level  of  financial  activity,  as  well  as 
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The 


to  provide  some  as-needed  operational  data 
overnight  response  request  will  result  in  a batch 
run  activated  during  nonprime  time  (evening  or 
weekend) . The  output  will  be  produced  on  Building 
12  printers  and  delivered  to  PHD  at  the  beginning  of 
the  following  work  day. 


1.3. 2. 2 Ad  _h oc _i n qu i r i es . In  addition  to  the  set  of 
predefined  inquires  to  be  available  to  the  user,  IFHS  must 
also  have  an  ad  hoc  inquiry  capability.  This  capability, 
while  more  difficult  to  use  than  the  predefined  inquiries, 
will  permit  selected  FBD  personnel  to  compose  new  inquiries. 
These  personnel  will  have  to  be  trained  in  the  inquiry 
language  and  in  some  aspects  of  the  IF„S  data  base 
structure.  The  specific  user  language  for  ad  hoc  inquiries 
is  defined  within  the  System  2000  documentation. 


1.3.3  IFMS  Reporting 

The  IFMS  reporting  requirements  wore  developed  by 
evaluating  existing  reports  and  incorporating  any  necessary 
or  desirable  modifications.  Existing  reports  were 
eliminated,  combined,  and  changed  and  some  new  reports  added 
based  on  new  IFMS  concepts- 

l primary  consideration  in  developing  IFMS  reporting 
requirements  was  to  minimize  the  system  paper  output  by: 
(1)  designing  efficient  formats,  (2)  providing  only  that 
information  that  is  not  better  obtained  by  inquiries,  (3) 
adjusting  report  frequency,  (4)  distributing  reports  to  only 
personnel  needing  the  reports,  and  (5)  making  use  of 
microfiche  output. 
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The  specific  IFMS  report  formats  and  descriptions  are 
presented  in  section  2.19.  These  reports  will  be  produced 
in  the  batch  processing  environment  of  IFMS. 

1.3.4  IFMS  Interfaces 

IFMS  must  continue  to  interface  with  other  FMD  and  JSC 
computer  systems.  The  method  of  interfacing  may  change 
during  the  first  two  phases  of  IFMS  with  the  optimum 
interfaces  being  developed  in  Phase  3.  Initially#  only 
batch  interfacing  will  be  supported  until  other  interfacing 
online  systems  are  implemented  at  JSC.  The  specific 
interface  requirements#  both  input  and  output#  are  presented 
in  section  2.17. 

1.4  SYSTEM  DESIGN  ASSUMPTIONS  AND  CONSTRAINTS 


IFMS  will  be  designed  with  both  online  and  batch 
processing  capabilities.  Online  capabilities  will  provide 
for  online  edit  and  update  of  most  daily  accounting 
transactions  and  for  online  inquiry  capability.  The  batch 
processing  capability  will  include:  (1)  recurring 
reporting,  (2)  interfaces  with  other  systems,  and  (3)  edit 
and  update  of  some  accounting  transactions.  It  is  assumed 
that  a CMS  and  DMS  that  meet  all  IFMS  requirements  (see 
sections  2.23  and  2.24)  will  be  available  when  needed.  The 
following  CMS/DMS  delivery  dates  have  been  assumed: 
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Needed 

Schedule  Impact 

DMS 

Single  thread 

11/74 

12/74 

Multi  thread 

01/75 

05/75 

CMS 


Simulator 

12/74 

12/74 

System 

02/75 

04/75 

The  computer  programs  for  online  processing  will  be 
written  in  FORTRAN  V,  and  the  report  and  interface  programs 
will  be  written  in  ANSI  COBOL.  IFMS  programs  will  interface 
with  both  CMS  and  DMS.  The  extent  to  which  the  various 
features  of  CMS  and  DMS  are  used  will  be  determined  during 
the  functional  design  phase  after  a critical  evaluation  of 
their  capabilities  and  performance. 

1.5  EQUIPMENT  REQUIREMENTS  AND  CONSTRAINTS 


IFMS  will  be  designed  for 
1108  computer  under  EXEC 
communications  hardware  must 
terminal  reguirements  specified 
with  full  production  use  of 
February  1976. 

FY  75 

Q 1 Q2  Q3  Q4 

Terminals  12  6 6 


operation  on  the  IDSD  UNIVAC 
8 control.  Sufficient 

be  available  to  support  the 
in  the  following  timetable 
the  terminals  beginning  in 

FY  76  FY  77  FY  78 

18  18  18 


One  remote  printer  must  be  available  in  fiscal  year 
1976  and  will  be  located  in  Building  416. 
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2 . 0  SYSTEM_RE£OIREMENTS 


2.1  SYSTEM  OVERVIEW 


The  requirements  that  the  IFMS  software  must  satisfy 
are  the  result  of  the  integration  of  the  basic  accounting 
requirements  of  each  operating  unit  within  FMD  and  its 
financial  reporting  requirements  to  JSC  management!,  other 
JSC  organizations,  and  NASA  Headquarters.  This  section 
presents  a discussion  of  FMD  financial  concepts  that  are 
basic  for  an  understanding  of  IFMS  requirements  and  an 
overview  of  the  organization  used  in  the  requirements 
definition. 

2.1.1  Concepts 


Three  major  financial  concepts  are  applicable  to  the 
operations  within  FMD:  (1)  Fund  Control,  ( 2 ) Funding  Cycle, 
and  (3)  Carrier  account.  These  concepts,  as  defined  in  the 
existing  batch  processing  computer  systems,  were  described 
in  the  IFMS  PIP.  Review  of  FMD  requirements  for  IFMS  has 
shown  that  the  Fund  Control  and  Funding  Cycle  concepts  can 
be  streamlined  to  eliminate  activities  not  essential  to  FMD 
operations  while  maintaining  the  required  accounting 
controls.  These  concepts  will  be  referenced  throughout  the 
discussion  of  IFMS  requirements. 


A > 
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2.  1.1.1  Fund The  FMD  Fund  Control  concept 

relates  to  the  processing  requirements  for  Resources 
Authority  (RA) , Allotment,  and  Primary  Work  Authorization 
(PWA) . Pund  Control  can  be  viewed  as  a series  of  "accounts" 
designed  to  manage  and  control  funds  received  for  JSC 
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projects  and  activities.  These  accounts  include  direct  and 
reimbursable  work  received  from  NASA  Headquarters,  work 
received  from  other  NASA  centers,  and  JSC  tracking  of  work 
given  to  other  NASA  centers  by  JSC. 

Each  of  the  accounts  or  subaccounts  described  contains 
the  receipts  and  the  issues.  An  account  or  subaccount 

balance  can  be  computed  as  the  difference  between  the 
receipts  and  the  issues.  Figure  2.1-1  illustrates  this 
account  structure. 

• Resources  Authority  - The  RA  account  contains 
authorizations  (within  the  limits  of  the  funds 
allotted)  for  the  commitment  and  obligation  for 
approved  projects  and  activities.  These 

authorizations  are  received  in  the  form  of  RA  and 
are  recorded  by  RA  type  in  one  of  three  subaccounts. 
All  subaccounts  record  RA  by:  (1)  appropriation 

type  [ Resources  and  Program  Management  (R&PM) , 
Research  and  Development  (R6D) , and  Construction  of 
Facilities  (C  of  F)  ],  (2)  Program  Year  (PY)  , and  (3) 

for  R&D  and  C of  F by  program  [defined  by  the  three- 
and  four-digit  Primary  Work  Code  (PWC) 
respectively  }. 

(1)  Direct  - The  Direct  RA  subaccount  contains  RA 
authorizations  received  directly  from  NASA 
Headquarters  for  approved  NASA  projects  and 
activities. 

(2)  Sub-RA  Received  - The  Sub-RA  Received 
subaccount  contains  the  RA  authorizations 
issued  to  JSC  from  other  NASA  centers  for 
support  work  to  be  performed  by  JSC. 
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Figure  2.1-1.  - Fund  Control  accounts  structure. 


(3)  Reimbursable  - The  Reimbursable  RA  subaccount 
contains  the  RA  authorizations  issued  to  JSC  as 
a result  of  anticipated  receipt  of  reimbursable 
work  performed  for  other  government  agencies  or 
private  individuals,  firms,  or  corporations. 
All  expenditures  made  for  reimbursable  work 
will  be  recovered  from  the  organization 
requesting  the  work. 

• Allotment  - The  Allotment  account  contains  the 
specific  funds  authorizations  (allotments)  that  are 
the  legal  limitations  on  commitments,  obligations, 
and  expenditures.  Allotments  received  are  recorded 
according  to  type  in  one  of  four  subaccounts  by 
appropriation  type  and  PY. 

(D  Direct  - The  Direct  Allotment  subaccount 
contains  the  specific  funds  authorizations  for 
work  ' performed  by  JSC  on  projects  and 
activities  authorized  through  Direct  RA's. 

(2)  Sub- Allotment  Received  - The  Sub-Allotment 
Received  subaccount  contains  the  specific  funds 
authorizations  for  work  performed  by  JSC  on 
projects  and  activities  authorized  through  Sub- 
RA*s  received  from  other  NASA  centers. 

(3)  Reimbursable  Suspense  - The  Reimbursable 
Suspense  subaccount  contains  the  funds 
authorizations  issued  as  a result  of 
anticipated  reimbursable  work.  This  subaccount 
is  an  intermediate  account  not  available  for 
the  funding  of  JSC  work  authorizations. 

(4)  Reimbursable  - The  Reimbursable  Allotment 
subaccount  contains  the  funds  authorizations 
for  specific  reimbursable  work  accepted  by  JSC. 
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This  subaccount  records  reimbursable 

acceptances  by  unique  nine-digit  PWC's  assigned 
to  each  order  in  addition  to  the  appropriation 
type  and  PY. 

• Conventional  PWA  - The  Conventional  PWA  account 
contains  the  distribution  of  JSC  authorized  funds  by 
the  responsible  budget  offices  based  on  the  JSC 
Program  Operating  Plan  (POP)  and  knowledge  of  the 
work  to  be  performed.  Funds  are  assigned  to  this 
account  by  Method  of  Authorization  (MA)  (i.e., 
direct  from  NASA  Headquarters,  by  center  for 
subauthorizations  received,  or  by  reimbursable 
order) , PY,  Fund  Source  (FS)  (a  further  breakdown 
within  appropriation  type) , and  PWC  for  all  R&D  and 
C of  F appropriations  or  Object  Class  for  all  R&PM 
appropriations.  These  funds  are  available  directly 
for  commitments,  obligations,  and  expenditures. 

• Reservation  PWA  - The  Reservation  PWA  account 

contains  funds  reserved  for  the  funding  of  the 
established  JSC  Carrier  account.  (The  Carrier 

account  concept  is  defined  in  the  IFMS  PIP.)  The 
account  contains  the  funds  reserved  for  Carrier 
account  funding  and  designated  by  MA,  PY,  FS, 
Responsible  Organization  (RO) , PWC  or  Object  Class, 
and  an  identification  of  the  Carrier  account 
receiving  the  funds.  This  account  is  maintained  so 
that  Carrier  account  actions  may  be  properly 
distributed  to  the  funding  project  or  activity. 

« Carrier  Account  - The  Carrier  account  is  composed  of 
a set  of  subaccounts  that  receive  the  funds  set 
aside  by  the  Reservation  PWA* s.  Common-use  services 
and  common-use  supplies,  materials,  and  noncapital 
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equipment  are  funded  by  means  of  the  subaccounts 
within  the  Carrier  account. 

• Sub-RA  PBA  - The  Sub-RA  PWA  account  records  RA's 

issued  to  other  NASA  centers  by  JSC.  The  RA*s 

issued  are  recorded  by  HA,  PY,  FS,  PNC  (R&D  and  C 
of  F only) , and  a receiving  center  identifier. 
Commitments,  obligations,  aad  expenditures  reported 
to  JSC  by  the  receiving  centers  are  recorded  against 
these  funds. 

• Sub  Issued  Suspense  - The  Sub  Issued  Suspense 
account  is  a control  account  used  to  track  allotment 
status  from  the  time  the  Sub-RA  is  issued  until  the 
notification  that  NASA  Headquarters  has  issued 
allotment  to  the  center  receiving  Sub-RA.  The 
account  is  used  also  to  track  JSC  withdrawal  of  Sub- 
RA  issued  to  another  center  from  the  time  the 
withdrawal  notification  is  sent  to  the  other  center 
until  NASA  Headquarters  returns  the  funding 
allotment  to  JSC. 

• Reimbursable  Order  Control  - The  Reimbursable  Order 

Control  account  is  a control  account  used  to  record 
the  total  dollar  amount  of  each  reimbursable  order. 
In  addition,  the  account  is  used  to  record  the 
detailed  history  information  of  every  basic 

reimbursable  order  and  the  amendments  to  each. 

2.1. 1.2  Funding  Cycle.  The  JSC  Funding  Cycle  is 
described  by  a set  of  four  accounts  used  to  control  and 
record  actual  commitments,  obligations,  and  expenditures 
incurred  for  all  JSC  projects  and  activities.  These 
accounts  are  commonly  identified  by  commitment,  obligation. 
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cost,  and  disbursement  (COCD) . The  information  recorded  in 
the  accounts  is  referred  to  as  performance  data. 

• Commitment  - The  Commitment  account  records  the 

reservation  of  RA  and  Allotment  based  on  firm 
requisitions,  procurement  requests,  authorizations 
to  execute  contracts,  or  other  written  evidence  that 
authorizes  the  creation  of  obligations  without 
further  recourse  to  the  official  responsible  for 
certifying  the  availability  of  funds. 

• Obligation  - The  Obligation  account  records  the 

amount' of  funds  legally  obligated  to  orders  placed, 
contracts  awarded,  services  rendered,  etc.  for  which 
disbursement  of  money  must  be  made. 

• Cost  - The  Cost  account  records  those  costs 
attributed  to  orders  placed,  contracts  awarded, 
services  rendered,  etc.  Costs  can  be  recorded  based 
on  actual  receipt  of  goods  or  services,  invoices 
from  suppliers,  or  cost  accrual  actions. 

• Disbursement  - The  Disbursement  account  records  all 
disbursements  of  funds  made  by  JSC. 

2.1.2  Processes 

The  magnitude  of  the  problem  that  IFMS  must  solve  and 
the  number  of  requirements  placed  on  the  system  make  it 
necessary  to  segment  the  requirements  presentation.  During 
the  requirements  analysis,  the  requirements  for  one  activity 
often  were  observed  to  cross  internal  FMD  organizational 
lines  and,  in  some  instances,  included  requirements 

generated  by  organizations  external  to  FMD.  Therefore,  a 
functional  division  of  the  requirements  was  made  to  view  the 
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requirements  of  any  activity  as  a unit*  These  divisions 
were  tagged  "processes"  and  are  used  as  the  basic  elements 
of  this  presentation*  In  addition  to'  the  processes  defined 
for  the  actual  operations  within  FMD,  other  processes  have 
been  defined  to:  (1)  include  requirements  generated  as  a 

result  of  required  interfaces  with  other  existing  computer 
systems  used  to  support  other  accounting  and  reporting 
activities  of  JSC  and  (2)  specify  the  requirements  for  a 
communications  management  system  (CHS)  and  data  management 
system  (DMS)  required  for  the  operation  of  IFMS. 

As  stated  in  the  IFMS  PIP,  system  requirements  are  to 
be  defined  in  three  phases  with  phase  one  defined  as  the 
replacement  of  the  existing  Basic  Accounting  System  (BAS) . 
The  requirements  stated  by  process  are  phase  one 

requirements.  Within  each  process,  the  input,  processing, 
output,  query,  and  reports  requirements  are  defined  where 
applicable.  The  section  also  includes  a brief  discussion  of 
phase  two  and  phase  three  requirements.  The  following  is  a 
brief  description  of  each  process  defined. 

• Resources  Authority  - The  Resources  Authority 

process  includes  the  accounting  for  tne 

authorizations  for  approved  JSC  projects  and 
activities.  RA's  define  the  maximum  funding  level 
authorized  for  any  project  or  activity.  The  Central 
Resources  Control  Section  has  the  primary 

responsibility  for  this  process. 

• Allotment  - The  Allotment  process  includes  the 

accounting  for  the  funds  allotted  to  all  approved 

JSC  projects  and  activities.  The  allotments  reflect 
the  legal  expenditure  limitations  for  JSC.  The 
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Central  Resources  Control  Section  has  the  primary 
responsibility  for  this  process. 

• Primary  Work  Authorization  - The  PWA  process 
includes  the  recording  and  maintenance  of  the 
distribution  of  JSC  authorized  funds  made  by  the 
budget  offices  based  on  the  JSC  POP.  The  Central 
Resources  Control  Section  has  the  primary 
responsibility  for  this  process. 

• Reimbursable  Order  Acceptance  - The  Reimbursable 
Order  Acceptance  process  includes  the  recording  of 
the  acceptance  of  all  reimbursable  orders  and  the 
dollar  amount  authorized  for  each  by  the  Central 
Resources  Control  Section. 

• Purchase  Request  - The  Purchase  Request  process 
includes  funds  availability  certification  and  the 
recording  and  maintenance  of  commitments  for  all 
documents  (except  travel  documents)  requiring  this 
action  prior  to  a procurement  action.  The  Fund 
Control  Unit  has  the  primary  responsibility  for  this 
process. 

• Obligation  - The  Obligation  process  includes  the 

recording  and  maintenance  of  the  obligations  of 
funds  (except  travel  funds)  made  by  JSC.  The 

recording  of  certain  obligations  (e.g.,  as  a result 
of  a n BPA  call”  action)  also  requires  the  recording 
of  a commitment.  The  Fund  Control  Unit  has  the 
primary  responsibility  for  this  process. 

• Cost  Accrual  - The  Cost  Accrual  process  includes  the 

periodic  accumulation  of  costs  attributed  to  all 
open  contracts  and  orders.  Both  manual  and 

automatic  procedures  are  used  to  determine  cost 
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accruals.  The  Cost  Accounting  Section  has  the 
primary  responsibility  for  this  process. 

Cost  Distribution  - The  Cost  Distribution  process 
includes  the  distribution  of  costs  through  the  JSC 
Carrier  account  to  the  proper  benefitting  PWC's  and 
organizations.  The  Cost  Accounting  Section  has  the 
primary  responsibility  for  this  process. 

Disbursement  — The  Disbursement  process  specifies 
whether  a payment  should  be  authorized  and  records 
the  payment  when  it  has  been  made.  The  Commercial 
Unit  has  the  primary  responsibility  for  this 
process. 

Sub-Authorization  Performance  - The  Sub- 
Authorization  Performance  process  includes  the 
recording  of  performance  data  (commitment, 
obligation,  cost,  and  disbursement)  reported  to  JSC 
by  other  NASA  centers  that  have  received  program 
support  work  from  JSC,  authorized  by  Sub-Resources 
Authority.  The  Fund  Control  Unit  has  the  primary 
responsibility  for  this  process. 

Travel  - The  Travel  process  includes  the  commitment, 
obligation,  costing,  and  disbursement  of  all  funds 
required  for  travel  and  permanent  change-of-station 
activities  of  JSC  employees  and  others  whose 
expenses  are  paid  by  JSC.  The  Travel  Unit  has  the 
primary  responsibility  for  this  process. 

Accounts  Receivable  - The  Accounts  Receivable 
process  includes  the  establishment,  billing,  aging, 
and  liquidation  of  JSC  Accounts  Receivable.  The 
Fund  control  Unit  has  the  primary  responsibility  for 
this  process. 
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Payroll  - The  Payroll  process,  as  it  relates  to 
IFMS,  includes  the  reservation  of  funds  (commitment 
and  obligation)  and  the  recording  of  the  costs  and 
disbursements  made  that  relate  to  payroll.  The 
Payroll  Unit  has  the  primary  responsibility  for  this 
process. 

Property  - The  Property  process,  as  it  relates  to 
phase  one  of  IFMS,  is  the  recording  and 

reconcilation  of  inventory  costs  to  recorded 
receipts.  The  Property  Accounting  section  has  the 
primary  responsibility  for  this  process. 

Edit  Table  Maintenance  - The  Edit  Table  Maintenance 
process  includes  the  maintenance  of  allowable  data 
elements  recorded  in  the  system  and  used  for 

validation  of  all  input  data  elements.  The 

Accounting  Control  and  Reports  Section  has  the 

primary  responsibility  for  this  process. 

External  System  Interfaces  - The  External  System 
Interfaces  process  is  the  identification  of 

information  provided  to  IFMS  by  other  computer 
systems  and  information  that  must  be  provided  to 
other  systems  by  IFMS. 

General  Inquiry  Requirements  - The  General  Inquiry 
Requirements  process  is  the  identification  of  data 
inquiries  not  applicable  to  any  specific  process. 
General  Report  Requirements  - The  General  Report 
Requirements  process  includes  the  identification  and 
definition  of  all  reports  to  be  generated  by  IFMS. 
End-of-Tear  - The  End-of-Year  process  is  the 
identification  and  definition  of  all  system 
functions  that  must  be  performed  to  reconcile  prior 
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year  entries,  close  all  accounts  for  the  year,  and 
open  all  required  accounts  for  the  new  fiscal  year. 

• Backup  Input  - The  Backup  Input  process  is  the 
definition  of  the  procedures  required  for  the  input 
of  data  to  IFMS  in  the  event  of  a catastrophic 
failure  of  the  online  input  equipment. 

• Miscellaneous  and  Others  - The  Miscellaneous  and 
Others  process  includes  any  requirements  not 
assigned  to  any  of  the  other  processes  defined. 

• CMS  Requirements  - The  CMS  Requirements  process 
defines  IFMS  requirements  in  the  area  of 
communications  support. 

• DMS  Requirements  - The  DMS  Requirements  process 
defines  IFMS  requirements  for  support  in  the 
management  of  data  required  in  an  IFMS  data  base. 
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2.2  RESOURCES  AUTHORITY  PROCESS 

Notification  of  the  funding  levels  budgeted  for 

approved  projects  and  activities  is  sent  to  each  NASA  center 
from  NASA  Headquarters  by  means  of  RA.  When  combined  with 
specific  funding  level  limitations  (allotments) , RA  is  the 
authority  and  control  used  by  JSC  for  all  commitments, 
obligations,  and  expenditures. 

RA  is  divided  into  the  following  four  categories: 

• Direct  Resources  Authority  - RA  issued  to  JSC  by 
NASA  Headquarters  for  purposes  of  planning  program 
expenditures  prior  to  receipt  of  actual  allotment. 

• Reimbursable  Resources  Authority  - RA  issued  to  JSC 
by  NASA  Headquarters  based  on  estimated  reimbursable 
work  to  be  performed  by  JSC.  Reimbursable  orders 
may  be  accepted  by  JSC  up  to  the  Reimbursable 
Resources  Authority  limitation  in  conjunction  with 
the  Reimbursable  Allotment  limitation  provided  by 
NASA  Headquarters. 

• Sub-Resources  Authority  Received  - RA  issued  to  JSC 
by  another  center.  It  provides  the  limitations  for 
program  support  work  to  be  performed  at  JSC.  NASA 
Headquarters  will  provide  Sub- Allotment  Authority  to 
JSC  based  on  the  other  center's  RA  issued  to  JSC. 

• Sub-Resources  Authority  Issued  - RA  issued  to 
another  center  by  JSC.  It  provides  the  limitations 
for  program  support  work  to  be  performed  by  the 
receiving  center  for  JSC. 
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The  Direct  Resources  Authority,  Reimbursable  Resources 
Authority,  and  Sub-Resources  Authority  Received  are  to  be 
input  into  the  online  system  as  RA  Received  transactions. 
The  input,  processing,  and  output  requirements  for  these 
transactions  are  very  similar  and  thus  are  not  separated  for 
discussion. 

The  Sub-Resources  Authority  Issued  is  initiated  through 
a PWA  transaction  and  is  discussed  in  the  PWA  process. 

2.2.1  Update  Requirements 

JSC  receives  notification  of  its  authorized  RA  on  the 
Resources  Authority  Warrant  (NASA  Form  506a) . This  form  is 
received  by  the  Central  Resources  Control  Section,  where  the 
information  is  to  be  entered  into  the  online  system.  The 
dollar  amounts  of  RA  received  must  update  the  receipts  of 
the  RA  subaccount  established  for  the  type  of  RA  received. 

“ The  information  that  must  be  input  for  the  RA 
received  and  the  edits  to  be  performed  are  described  in 
figure  2.2-1.  The  template  to  be  used  for  the  RA  receipts 
data  input  is  shown  in  figure  2.2-2. 

Processing  - All  RA' s received  must  be  posted  to  the  RA 
subaccount  defined  by  the  type  of  RA  (Direct,  Reimbursable, 
and  Snb-RA  Received).  The  subaccount  entry  to  which  the 
posting  is  to  be  made  is  defined  by  the  data  elements  MA, 
PY,  and  FS  for  all  appropriations  (R&PM,  R&D,  and  C of  F)  . 
In  addition,  a three-digit  PWC  is  used  if  the  appropriation 
is  R&D,  and  a four-digit  PWC  is  used  for  the  C of  F 
appropriation. 
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Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  Must  be  numeric  and  con- 
form to  all  normal  date  edits. 

B100 

B101 

Control 

Number 

Yes 

User 

supplied 

Fatal 

Identification  number  of  RA  source  document. 

Input  for  all  Resources  Authority  Received 
transactions.  Must  be  numeric  and  greater  than  0. 

B910 

B911 

B912 

Method  of 
Authority 

Yes 

Form  506a 

Fatal 

Input  for  all  Resources  Authority  Received  trans- 
actions. Must  be  6M  or  be  numeric  and  entered  as 
follows: 

B 1 1 0 

Bill 

B112 

Typ«=>  of  transaction  Value 

Direct  RA  00 

Sub-RA  10-79 

Reimbursable  RA  99 

Program  Year 

Yes 

Form  506a 

Fatal 

Input  for  all  Resources  Authority  Received  trans- 
actions. Must  be  a valid  PY.  Also  validated 
with  FS. 

B120 

B121 

C500 

Dollar 

Amount 

Yes 

Form  506a 

Fatal 

Input  for  all  Resources  Authority  Received  trans- 
actions. Must  be  numeric  and  not  egual  to  0. 

B120 
B 1 41 
B 1 42 

Type  of 
funding 

Yes 

User 

supplied 

Fatal 

Transaction  modifier  for  all  Resources  Authority 
Received  transactions;  indicates  the  appropriation 
type.  One  and  only  one  type  of  funding  must  be 
specified. 

B020 

B021 

Fund  Source 

Yes 

Form  506a 

Fatal 

Input  or  generated  as  follows  depending  on  the  type 
of  funding  specified  on  the  template: 

B 130 
B132 
B 133 

Tvoe  of  fundinq  Value  Infiut^Edit 

RSPM  1 None  (generated) 
RGD  4,9.11  Specific  values 
C of  F 5-8  Specific  values 
Other  All  of  above  Specific  values 

B134 

C500 

Also  validated  with  PY. 

Primary 
Work  Code 

Conditional 

Form  506a 

Fatal 

Input  as  follows  depending  on  the  type  of  funding 
specified  on  the  template- 

B170 
B 172 
B173 

Tvpe  of  fundinq  Value 

R5PM  Blank 

R&D  Three-digit  PWC 

C of  F Four-digit.  PHC 

Other  Any  of  above 

Correction 

Optional 

User 

supplied 

None 

Transaction  modifier  for  all  Resources  Authority 
Received  transactions.  Specified  only  when  the 
transaction  is  correction. 

None 

Figure  2.2-1. 

- Resources 

Authority  input  and  edit  requirements. 

♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

.♦♦♦♦TEMPLATE  NO.  FI  - RESOURCES  AUTHORITY 
CONTROL  NO. 

MA  PY  RESOURCES  AUTHORITY  $ 

TYPE  OF  FUNDING: 

R&PM 

R&D  _ FS  PWC 

C OF  F FS  PNC 

OTHER  _ FS  PWC 

CORRECTION 


Figure  2.2-2 


Resources  Authority  template 


If  a BA  subaccount  entry  has  not  been  established  for 
the  RA  being  input  in  a RA  Received  transaction,  the  sub- 
account entry  must  be  generated  using: 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Primary  Work  Code  (if  applicable) 

• Dollar  Amount  (receipts) 

A negative  dollar  amount  is  not  permitted  when  a subaccount 
entry  must  be  established. 

If  the  input  RA  Received  transaction  defines  a 
subaccount  entry  already  established,  the  subaccount  entry 
receipts  must  be  updated  with  the  input  dollar  amount, 
provided  the  action  would  not  result  in  a negative  account 
balance. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  input  and  correction  transactions  will  be  identified 
in  the  transaction  history. 

Output  - Section  2.2.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  RA  transaction. 
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1 


i 


J 


1 


I 


2.2.2  Output  Message  Requirements 

Figures  2.2-3  through  2.2-6  contain  a list  of  output 
message  requirements.  Figure  2.2-7  contains  a correlation 
of  output  messages  by  RA  transactions. 

2.2.3  Inquiry  Requirements 

Figure  2.2-8  contains  a list  of  inquiry  input  data 
elements  and  response  data  elements  required  for  RA 

processing . 

2.2.4  Report  Requirements 

Section  2.19.1  lists  the  Fund  Control  report 
requirements.  The  following  reports  reflect  RA  account 
activity: 

• Fund  Control  Account  Status-Part  I Resources  Authority 

• Resources  Authority  Versus  Allotment  Exceptions 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  Resources  Authority  Section  report 
described  in  section  2.19.7. 
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Code 


Message 


**** 

RESOURCES 

AUTHORITY 

RECEIVED 

TRANSACTION  - RSPM 

FUNDING 

RESOURCES 

AUTHORITY 

RECEIVED 

TRANSACTION  - RSD  FUNDING 

**** 

RESOURCES 

AUTHORITY 

RECEIVED 

TRANSACTION  - C OF 

F FUNDING 

**** 

RESOURCES 

AUTHORITY 

RECEIVED 

TRANSACTION  - OTHER 

FUNDING 

B020 

TYPE  OF  FUNDING  NOT 

SPECIFIED 

B021 

MULTIPLE 

TYPES  OF  FUNDING  SPECIFIED 

Figure  2,2-3.  - Resources  Authority 
transaction- begun  messages. 

Code  Message 

A000  PROCESSING  COMPLETE 

A 1 00  RESOURCES  AUTHORITY  RESULTS 

MA PY FS PWC 

OLD  RECEIPTS  $_# , , . UPDATE  $ ,t , . ± 

NEW  RECEIPTS  , , . 

Figure  2.2-4.  - Resources  Authority 
transaction-corn plete  messages. 
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J 
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Code  Message 

B 1 00  'AS  OF'  DATE  INVALID 

B 1 01  'AS  OF*  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE 

B 1 1 0 MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 1 2 MA  MUST  BE  00,  10  TO  79,  OR  99 

B 1 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

B 1 30  FS  NOT  ENTERED 

B 1 32  FS  MUST  BE  4,  9,  OR  11 

B 133  FS  MUST  BE  5 TO  8 

B 1 34  FS  MUST  NOT  BE  2 OR  3 

B170  PWC  NOT  ENTERED 

B 1 71  PWC  INVALID 

B 1 72  PWC  MUST  BE  3 DIGITS 

B 1 73  PWC  MUST  BE  4 DIGITS 

B600  $ AMOUNT  NOT  ENTERED 

B601  $ AMOUNT  INVALID 

B 6 02  $ AMOUNT  MUST  NOT  BE  ZERO 

B910  CONTROL  NUMBER  NOT  ENTERED 

B911  CONTROL  NUMBER  INVALID 

B9 1 2 CONTROL  NUMBER  MUST  BE  GREATER  THAN  ZERO 
C500  PY,  FS  COMBINATION  INVALID 


Figure  2.2-5.  - Resources  Authority 
data  element  edit  error  messages. 
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Code 


Message 


D 1 00 
D 101 


Figure 


RESOURCES  AUTHORITY  RECORD  NOT  FOUND 

MA PY FS PWC 

RESOURCES  AUTHORITY  BALANCE  INSUFFICIENT  TO 
DECREASE  RECEIPTS 
MA PY FS PMC 

BALANCE  , , . UPDATE  $_, , _ 


.2-6.  - Resources  Authority  processing  error  messages. 


Transaction 

Direct 

R&PM  funding 
BSD  funding 
C OF  F funding 
Other  funding 

S^bzHecei ved 
R&PM  funding 
R&D  funding 
C of  F funding 
Other  funding 

Esisbur sable 
R&PM  funding 
R&D  funding 
C of  F funding 
Other  funding 


Message  ft 
0 
0 
0 


A.  B B B B B B 
10  0 1111 
0 2 2 0 0 1 1 
0 0 10  10  1 


B B B B B B B 

1111111 

1 2 2 2 3 3 3 

2 0 1 2 0 2 3 


B B B B B B 

111116 

3 7 7 7 7 0 

4 0 1 2 3 0 


BBBBBCDD 
6 6 9 9 9 5 1 1 
0 0 1 1 1 0 0 0 
1 2 0 1 2 0 0 1 


X X X X X X X X X 

xxxxxxxxx 

X X X X X X X X X 

xxxxxxxxx 


X X 
X X 
X X 
X X 


XX  XX 

X X XX 

X x X 


X 

X 


XXXXXX  XX 

xxxxxxxxx 

xxxxxxxxx 

xxxxxxxxx 


XXXXXX 

XXXXXX 

XXXXXX 

XXXXXX 


X X X X X 
X X X X X 
X X X X X 
X X X X X 


XX  XX 

X X XX 

X XX 


XXXXXX  XX 

X xxxxxxxxx 
xxxxxxxxxx 
xxxxxxxxx 


XX  xxxxxxxxx 
XX  xxxxxxx  xx 

XXXXXX  xxxxx 
XX  XXXXXXX  XX 


X X 
X X 

X 


XXXXXX  XX 
XXX  XXXX  XXXXX 
XX  XXXXXXXXXX 

X X xxxxxxxxx 


to 


to 

I 

o 


Figure  2.2-7.  - Resources  Authority  messages  by  transaction. 


Inquiry,  description 


Type 


Input  data  elements 


Timing 


E§££931  £ a elements 


( 


o o 

*=9  Pd 

*n  q3 

§a 

“A 

§s 

at 


a 


Resources  and  Program  Item 

Management  Resources 
Authority  Control  status 


Research  and  Development  Item 

Resources  Authority  Fund 
Control  status 


Construction  of  Facilities  Item 
Resources  Authority  Fund 
Control  status 


Resources  Authority  Fund  Summary 

Control  summary  at  Fund 
Source  level 


Resources  Authority  Fund  Summary 

summary  at  appropriation 

level 


Fund  Control  summary  at  Summary 

Program  Year  level 


Resources  Authority  Fund  Summary 

Control  summary  at  Method 
of  Authority  level 


Method  of  Authority  Immediate 

Program  Year 
Fund  Source 


Method  of  Authority  Imsediate 

Program  Year 
Fund  Source 
Primary  Work  Code 
(three  digits) 


Method  of  Authority  Immediate 

Program 
Fund  Source 
Primary  Work  Code 
(four  digits) 


Method  of  Authority  Immediate 

Program  Year 
Fund  Source 


Method  of  Authority  Immediate 

Program  Year 
Appropriation  type 


Method  of  Authority  'immediate 

Program  Year 


Method  of  Authority  Immediate 


Method  of  Authority 
Program  Year 
Fund  Source 

Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 
Last  receipts  activity  information 
Last  issue  activity  information 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (three  digits) 
Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 
Last  receipts  activity  information 
Last  issue  activity  information 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (four  digits) 
Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 
Last  receipts  activity  information 
Last  issue  activity  information 

Method  of  Authority 
Program  Year 
Fund  Source 

Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 

Method  of  Authority 
Program  Year 
Appropriation  symbol 
Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 

Method  of  Authority 
Program  Year 

Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 

Method  of  Authority 
Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 


Figure  2.2-8.  - Resources  Authority  inquiry  requirements- 


lies 


Resources  Authority  Summary 

Fund  Control  summary 
for  Proqram  Year  and 
appropriation  level 

Resources  Authority  List 

list  of  Method  of 

Authority 


Resources  Authority  List 

list  of  three-digit 
Primary  Work  Codes 


^ Resources  Authority  List 

i list  of  Primary  Work 

£ Codes  for  Program  Year 

and  appropriation 
level 


Resources  Authority  List 

General  Ledger  summary 


Figure  2.2-8. 


Timing 


Input  data  elements 


Response  data  elements 


Program  Year  Immediate  Program  Year 

Appropriation  type  Appropriation  symbol 

Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 

Program  Year  Immediate  Program  rear 

Fund  Source  Fund  Source 

Method  of  Authority 
Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 
Total  receipts 
Total  issues 
Total  balance 

Method  of  Authority 
Program  Year 
Fund  Source 

Dollar  limit  (on  balance) 

Primary  Work  Code  (three-digits) 
Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 

Program  Year  Same  day  Program  Year 

Appropriation  type  * Appropriation  symbol 

Fund  Source 
Method  of  Authority 

Primary  Work  Code  (three  or  four  digits) 
Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 

None  reguired  Same  day  Resources  Authority  receipts: 

Received  from  headquarters 
Received  from  other  centers 
Issued  to  other  centers 
Net  Resources  Authority 


Method  of  Authority  Immediate 

Program  Year 
Fund  Source 
Dollar  limit  (on 
balance) 


A 


Resources  Authority  inquiry  requirements  (concluded)  . 


2.3  ALLOTMENT  PROCESS 


Specific  funds  authorizations  for  approved  projects  and 
activities  are  provided  to  NASA  centers  by  NASA  Headquarters 
in  the  form  of  allotments.  The  allotments  received  by  JSC 
represent  the  legal  funding  level  limitations  placed  upon 
JSC  by  appropriation  and  are  the  controlling  limit  for  JSC 
commitments,  obligations,  and  expenditures. 

Allotments  are  divided  into  the  following  four 
categories : 

• Direct  Allotment  - Funds  authorizations  issued  to 
JSC  by  NASA  Headquarters  for  the  purpose  of  funding 
projects  and  activities  to  be  performed  at  JSC  and 
authorized  by  Direct  RA  issued  to  JSC. 

• Reimbursable  Allotment  - Funds  authorizations  issued 
to  JSC  to  support  the  acceptance  of  reimbursable 
orders  for  work  to  be  performed  by  JSC  for  other 
government  agencies  and  private  corporations,  firms, 
or  individuals.  Reimbursable  Allotment  must  be 
controlled  so  that  no  allotted  funds  are  released 
until  a reimbursable  order  is  accepted  by  JSC. 

• Sub-Allotment  Received  - Funds  authorizations  issued 
to  JSC  to  fund  RA  issued  to  JSC  from  other  RASA 
centers. 

• Sub-Allotment  Issued  - Funds  authorizations 
withdrawn  from  JSC  by  NASA  Headquarters  and 
transferred  to  another  NASA  center  to  fund  RA  issued 
to  another  NASA  center  by  JSC. 
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2.3.1  Update  Requirements 


JSC  receives  notification  of  its  allotments  by  the 
Allotment  Authorization  (NASA  Form  504) . This  form  is 
received  by  the  Central  Resources  Control  Section,  where  all 
information  provided  is  to  be  entered  into  the  online 
system.  The  dollar  amounts  of  the  allotments  must  be  input 
into  the  Allotment  subaccount  specified  by  the  type  of 
allotment  at  the  appropriation  level  FS.  The  appropriation 
level  FS  is  defined  as  FS  1 for  R&PM,  FS  4 for  R&D,  and  FS  5 
for  C of  F.  The  input  of  this  data  is  defined  as  an 
Allotment  Received  transaction. 


R&PM  allotments  can  be  received  with  specific  funding 
limitations  on  travel  expenditures  that  must  be  recorded 
under  a separate  FS  (FS  2)  and  must  reduce  the  dollar  amount 
recorded  for  R&PM  allotments  at  the  appropriation  level  FS 
(FS  1) . R&PM  allotments  can  also  be  transferred  to  a third 
FS  (FS  3)  with  a like  reduction  of  the  allotment  at  the 
appropriation  level  FS  (FS  1) . For  the  purpose  of  later 
discussion,  the  level  FS  existing  after  this  subdivision 
be  defined  as  the  funding  level  FS  and  will  include  at 
maximum  FS's  1,  2,  3,  4,  and  5.  This  transfer  of  the  R&PM 
allotments  is  defined  as  a R&PM  Allotment  Transferred 
transaction.  No  similar  requirements  exist  for  the 
subdivision  of  R&D  and  C of  F allotments.  Because  no 
distinction  is  made  between  FS  1 at  the  appropriation  and 
funding  levels,  the  appropriation  level  FS  for  R&PM  must  be 
the  sum  of  the  R&PM  funding  FS's  1,  2,  and  3. 

Information  specifying  withdrawal  of  allotment  by  NASA 
Headquarters  to  fund  RA  issued  to  another  center  by  JSC  is 


2.  3-2 


recorded  through  a third  allotment  transaction,  the  Sub 
Issued  transaction.  All  three  transactions  update  the 
receipts  of  the  Direct,  Reimbursable  Suspense,  or  Sub- 
Allotment  Received  subaccounts  of  the  Allotment  account. 
However,  because  the  requirements  for  each  transaction 
differ,  the  input,  processing,  and  output  requirements  will 
be  discussed  by  transaction. 

2.3. 1.1  Allotment Received.  The  receipt  of  funds 

authorizations  through  the  Direct  Allotment,  Reimbursable 
Allotment,  and  Sub- Allotment  Received  are  to  be  recorded  as 
an  Allotment  Received  transaction.  This  transaction  must 
also  permit • decreases  in  the  allotment  amounts. 

lEEiit  ~ The  «iata  elements  that  must  be  input  for  the 
Allotment  Received  transaction  and  the  edits  to  be  performed 
are  described  in  figure  2.3-1. 

The  template  to  be  used  for  this  transaction  is  shown 
in  figure  2.3-2.  This  same  template  will  be  used  for  the 
other  allotment  transactions  defined. 

~ All  allotments  received  must  be  posted  to 
the  Allotment  subaccount  defined  by  the  type  of  allotment 
(Direct,  Reimbursable,  or  Sub- Allotment  Received).  The 
subaccount  entry  to  which  the  posting  is  to  be  made  is 
defined  by  the  data  elements  MA,  PY,  and  appropriation  level 
FS.  If  the  subaccount  entry  does  not  already  exist  in  the 
data  base,  it  is  generated  with  tne  following  elements: 

• Method  of  Authority 

• Program  Year 
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Data 

element 


♦ ft  s of* 
Date 


Program  Year 


Dollar 

Amount 


Type  of 
transaction 


Method  of 
Authority 


Type  of 
funding 


Fund  Source 


Correction 


Amendment 

Number 


Element  Error 

required  Source  type_ 


Input/Edit  requirements 


Optional  User 

supplied 


Yes 


Form  504 


Fatal  Date  providing  for  the  backdating  of  transactions. 

Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

Fatal  Input  for  all  Allotment  Received  transactions. 

Must  be  a valid  PY.  Also  validated  in  combination 
with  MA  and  PS. 


Yes 


Form  504 


Fatal  Input  for  all  Allotment  Received  transactions. 
Must  be  numeric  and  not  equal  to  0. 


Yes  User 

supplied 


Yes 


Form  504 


Yes  User 

supplied 


Yes  Form  504 


Optional  User 

supplied 


Yes  Form  504 


Fatal 


Fatal 


Transaction  indicator.  Input  as  one  of  Direct 
Allotment  Received,  Sub-Allotmen t Received,  or 
Reimbursable  Allotment  Received;  only  one  type 
of  transaction  may  be  specified. 

Input  or  generated  as  follows  depending  on  the  type 
of  transaction  specified  on  the  template; 


Type  of  Transaction  Value 

Direct  Allotment  Received  00 
Sub-Allotment  Received  10-79 

Reimbursable  Allotment  97 

Received 


Input/Edit 
None  (generated) 
Numeric,  range 
None  (generated) 


Also  validated  in  combination  with  PY  and  FS. 


Fatal  Transaction  modifier  indicating  the  appropriation 
type.  Input  for  all  Allotment  Received  trans- 
actions. One  and  only  one  type  of  funding  must 
be  specified. 

Fatal  Input  or  generated  as  follows  depending  on  the  type 
of  funding  specified  on  the  template; 


> of  funding 

Value 

Input/Edit 

RGPM 

1 

None  (generated) 

HDD 

4 

None  (generated) 

n of  f 

5 

None  (generated) 

ther 

1,<», 5 

Specific  values 

Also  validated  in  combination  with  MA  and  PY. 


None  Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the  trans- 
action is  a correction. 

Fatal  Identification  number  of  the  allotment  source 
document.  Input  for  all  Allotment  Received 
transactions.  Must  be  numeric  and  greater  than  0. 


Error 

code 


B 1 00 
B 1 0 1 


B120 

B121 

C501 


B600 

B601 

B602 

B0 1 0 
B01 1 


B 1 1 0 
Bill 
B113 
C501 


B020 

B021 


B130 
B135 
C50 1 


None 


B920 

B921 

B922 


Figure  2.3-1.  - Allotment  Received  input  and  edit  requirements, 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

****TEMPLATE  NO.  G1  - ALLOTMENT 

py ALLOTMENT  $ , , . ± AMENDMENT  NO. 

TYPE  OF  TRANSACTION: 

DIRECT  ALLOTMENT  RECEIVED  _ 

SUB-ALLOTMENT  RECEIVED  _ MA  

REIMBURSABLE  ALLOTMENT  RECEIVED  _ 

R&PM  ALLOTMENT  TRANSFERRED  _ MA  FS  

SUB  ISSUED  _ SUB  ID  

TYPE  OF  FUNDING: 

R&PM  _ R&D  C OF  F _ 

OTHER  _ FS  

CORRECTION 


Figure  2.3-2 


Allotment  template. 


• Fund  Source  (appropriation  level) 

• Dollar  Amount  (receipts) 

A negative  dollar  amount  will  not  be  permitted  when  a 
subaccount  entry  must  be  established. 

If  the  input  data  elements  define  a subaccount  entry 
already  established,  the  entry  receipts  must  be  updated  with 
the  input  dollar  amount,  provided  the  action  would  not 
result  in  a negative  subaccount  entry  balance. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  input,  update,  and  correction  transactions  will  be 
identified  in  the  transaction  history. 

Output.  Section  2.3.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Allotment  Received  transactions. 

2.3.  1.2  R&.RH Allotment Transferred.  The  R&PM 

Allotment  Transferred  transaction  transfers  allotments  from 
the  appropriation  level  FS  for  R&PM  to  the  funding  FS's 
defined  for  R&PM.  This  transaction  is  to  be  valid  only  for 
Direct  Allotment  and  Sub-Allotment  Received.  The  amount  of 
allotment  transferred  to  FS  2 is  the  travel  limitation 
amount  defined  in  the  R&PM  Allotment  Authorization  document. 
The  amount  of  allotment  transferred  to  FS  3 is  determined  by 
the  dollar  value  of  the  PHA's  that  must  be  funded  by  FS  3 
appropriations. 
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IHEUt  “ Figure  2.3-3  contains  a list  of  the  elements 
that  must  be  input  from  the  Allotment  Authorization  document 
for  the  transfer  transaction.  Figure  2.3-2  defines  the 
allotment  template  used  for  this  and  the  other  allotment 
transactions. 

~ The  selection  of  the  Allotment  subaccount 
entry  from  which  the  transfer  is  to  be  made  (transferor)  is 
determined  by  the  allotment  type  (Direct  Allotment  or  Sub- 
Allotment  Received)  and  the  data  elements  MA,  PY,  and 
appropriation  level  FS.  The  Allotment  subaccount  entry 
receiving  the  transfer  (transferee)  is  within  the  same 
subaccount  as  the  transferor.  The  data  elements  MA,  PY,  and 
input  funding  level  FS  specify  the  transferee  subaccount 
entry. 

The  transferor  subaccount  entry  must  exist  in  the  data 
base  for  the  transfer  transaction  to  be  valid.  The 
transferee  subaccount  entry  may  or  may  not  exist  in  the  data 
base.  If  the  subaccount  entry  does  not  exist,  that  entry 
must  be  generated  with  the  following  data  elements: 

• Method  of  Authority 

• Program  Year 

• Fund  Source  (funding  level) 

• Dollar  Amount  (receipts) 

A positive  dollar  amount  input  for  the  transfer 
transaction  must  result  in  a decrease  to  the  receipts  in  the 
transferor  subaccount  entry  and  an  increase  to  the  receipts 
in  the  transferee  subaccount  entry.  A negative  dollar 
amount  input  must  result  in  the  reverse 
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effect  on  a 


Error 

code 


Data 

element 

Element 

required 

Source 

Error 

t££e 

Input/Edit  requirements 

^ & 

% & 
8% 

i§ 

* As  of 
Date 

Optional 

User 

supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

program  Year 

Yes 

Form  504 

Fatal 

Input  for  all  R&PB  Allotment  Transferred  trans- 
actions. Bust  be  a valid  PY.  Also  validated  in. 
combination  with  BA  and  FS. 

Dollar 
A mount 

Yes 

Form  504 

Fatal 

Input  for  all  R&PM  Allotment  Transferred  trans- 
actions. Bust  be  numeric  and  not  equal  to  0. 

*& 

Type  of 
transaction 

Method  of 
Authority 

Yes 

Yes 

User 

supplied 
Form  504 

Fatal 

Fatal 

Transaction  indicator.  Input  as  R&PB  Allotment 
Transferred  transaction.  % 

Input  for  all  R&PB  Allotment  Transferred  trans- 
actions. Bust  be  numeric  and  either  00  or  in 
the  range  10-79.  Also  validated  in  combination 
with  PY  and  FS. 

NJ 

tu 

1 

CD 

Fund  Source 

Yes 

Form  504 

Fatal 

Input  for  all  R&PB  Allotment  Transferred  trans- 
actions. Bust  be  an  R&PB  funding  FS  other  than 
1.  Also  validated  in  combination  with  BA  and  PY. 

Type  of 
funding 

Correction 

Not 

entered 

Optional 

User 

supplied 

None 

Bust  not  be  input. 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction. 

Amendment 

Number 

Yes 

User 

supplied 

Fatal 

Identification  number  of  the  allotment  source 
document.  Input  for  all  B&PM  Allotment  ^ 
Transferred  transactions.  Bust  be  numeric  and 

greater  than  0. 


B100 

Bl  01 


Bl  20 
Bl  2 1 

C501 

ft 

B600 

B601 

B602 

B010 
B0 11 

Bl  1 0 
Bill 
Bl  1 6 

C501 

Bl  30 
Bl  36 
C501 
C502 

B022 


None 


B920 

B921 

B922 


Figure  2.3-3. 


R&PH  Allotment  Transferred  input  and  edit  requirements. 


transferor  and  transferee  subaccount  entries.  A negative 
account  balance  as  result  of  the  transfer  transaction  must 
not  occur. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  input,  update,  and  correction  transactions  will  be 
identified  in  the  transaction  history. 

0ut£ut  - Section  2.3.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  R&PH  Allotment  Transferred  transaction. 

2.3. 1.3  Sub Issued.  The  dollar  amount  of  the 

allotment  withdrawn  from  JSC  by  NASA  Headquarters  and 
transferred  to  another  NASA  center  to  fund  the  JSC  Sub— RA  to 
that  center  is  to  be  recorded  as  an  Allotment  Issued 
transaction  when  notification  of  the  action  is  received  in 
the  Allotment  Authorization  document.  This  transaction  must 
reduce  the  receipts  and  issues  of  the  Direct  Allotment 
subaccount  to  reflect  the  allotment  withdrawn  from  JSC  by 
NASA  Headquarters  and  must  remove  the  funds  suspensed  in  the 
Sub  Issued  Suspense  account  at  the  time  the  Sub-RA  was 
issued.  This  transaction  must  also  perform  the  opposite 
actions  when  the  allotment  is  returned  to  JSC  by  NASA 
Headquarters  as  a result  of  the  Sub-RA  withdrawn  by  JSC  from 
another  center. 

Ingut  — Figure  2.3-4  contains  a list  of  the  data 
elements  that  must  be  input  for  the  Sub  Issued  transaction 
and  the  edits  that  must  be  performed.  Figure  2.3-2  defines 
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Data 

element 

Element 

required 

Source 

Error 

t£pe 

Input/Edit  requirements 

1 As  of’ 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
System  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

Program  tear 

Yes 

Form  504 

Fatal 

Input  for  all  Sub  Issued  transactions.  Must  be 
a new  PY.  Also  validated  in  combination  with  MA 

and  FS. 

Dollar  Amount 

Yes 

Form  504 

Fatal 

Input  for  all  Sub  Issued  transactions.  Must  be 
numeric  and  not  equal  to  0* 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Transaction  indicator.  Input  as  Sub  Issued. 

Sub- 

authorization 

Identifier 

Yes 

Form  504 

Fatal 

Input  for  all  Sub  Issued  transactions.  Must  be 
numeric  and  in  the  range  10-79. 

Method  of 
Authority 

Yes 

Form  504 

Fatal 

Generated  for  all  Sub  Issued  transactions  as  00. 
Validated  in  combination  with  PY  and  FS. 

Type  of 
funding 

Yes 

User  supplied 

Fatal 

Transaction  modifier  indicating  the  appropriation 
type.  Input  for  all  Sub  Issued  transactions.  One 
and  only  one  type  of  funding  oust  be  specified. 

Fund  Source 

Yes 

Form  504 

Fatal 

Input  or  generated  as  follows  depending  upon  the 
type  of  funding  specified  on  the  template: 

Type  of  funding  Value  Input^dit 

~ 1 None  (generated) 

R5D  4 None  (generated) 

C of  F 5 None  (generated) 

Other  1,4,5  Specific  values 

Also  validated  in  combination  witfc  MS  and  PY. 

Correction 

Optional 

User  supplied 

None 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction. 

Amendment 

Number 

Yes 

user  supplied 

Fatal 

Identification  number  of  allotment  source  docu- 
ment. Input  for  all  Sub-Issued  transactions. 
Must  be  numeric  and  greater  than  0. 

Error 

code 


B100 

B101 


B120 

B121 

C501 

B600 

B601 

B602 

B010 
B0 1 1 

B160 

B161 

B162 

C501 


B020 

B021 


B130 

B135 

C501 


None 


B920 

B921 


Figure  2.3-4. 


- Sub  Issued  input  and  edit  requirements. 
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the  allotment  template  used  for  this  and  the  other  allotment 
transactions  defined. 

Processing  - Because  the  Sub  Issued  transaction  changes 
allotments  received  and  removes  funds,  suspensed  in  a prior 
transaction,  the  Direct  Allotment  subaccount  entry 
(identified  by  HA,  PY,  and  appropriation  level  FS)  and  the 
Sub  Issued  Suspense  account  entry  (identified  by  MA,  PY, 
appropriation  level  FS,  and  Sub  ID)  must  exist  in  the  data 
base.  The  receipts  and  issues  of  the  specified  Direct 
Allotment  subaccount  entry  must  be  changed  by  the  input 
dollar  amount  to  reflect  the  allotment  withdrawn  from  JSC  as 
the  result  of  a Sub-RA  issued  by  JSC  (a  negative  dollar 
input)  or  to  reflect  the  allotment  returned  to  JSC  as  the 
result  of  a Sub-RA  withdrawn  by  JSC  (a  positive  dollar 
input).  In  addition,  that  dollar  amount  must  be  posted  to 
the  Sub  Issued  Suspense  account  issues  with  the  reverse  sign 
to  remove  the  suspense  balance  created  by  the  Sub-RA  action. 

Any  update  in  the  Direct  Allotment  subaccount  must  not 
result  in  a negative  subaccount  entry  balance.  A negative 
entry  balance  in  the  Sub  Issued  Suspense  account  is  possible 
and  indicates  that,  a Sub-RA  issued  by  JSC  has  been  withdrawn 
from  another  center,  but  the  allotment  has  not  yet  been 
returned  by  NASA  Headquarters. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  input  and  correction  transactions  will  be  identified 
in  the  transaction  history. 
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Output  — Section  2.3.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Sub  Issued  transaction. 

2.3.2  Output  Message  Requirements 

i Figures  2.3-5  through  2.3-8  contain  a list  of  output 

message  requirements.  Figure  2.3-9  contains  a correlation 
of  output  messages  by  transaction. 

I 2.3.3  Inquiry  Requirements 

J Figure  2.3-10  contains  a list  of  inquiry  input  data 

elements  and  response  data  elements  required  for  allotment 
processing. 

2.3.4  Report  Requirements 

Section  2.19.1  lists  the  Fund  Control  report 
requirements.  The  following  reports  reflect  Allotment 
account  activity: 

• Fund  Control  Status  — Part  II  Allotment 

• Fund  Control  Status  - Part  III  Sub  Issued  Suspense 

• Resources  Authority  Versus  Allotment  Exceptions 

\ A list  of  valid  daily  transactions  must  appear  in  the 

j Daily  Transaction  List  Allotment  Section  report  described  in 

section  2.19.7. 

r ; 
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Code 


Message 


#***  DIRECT  ALLOTMENT  RECEIVED  TRANSACTION  - RSPM 

****  DIRECT  ALLOTMENT  RECEIVED  TRANSACTION  - RSD  FUNDING 

****  DIRECT  ALLOTMENT  RECEIVED  TRANSACTION  - C OF  F FUNDING 

****  DIRECT  ALLOTMENT  RECEIVED  TRANSACTION  - OTHER  FUNDING 

****  SUB-ALLOTMENT  RECEIVED  TRANSACTION  - RSPM  FUNDING 

****  SUB-ALLOTMENT  RECEIVED  TRANSACTION  - RSD  FUNDING 

****  SUB-ALLOTMENT  RECEIVED  TRANSACTION  - C OF  F FUNDING 

****  SUB-ALLOTMENT  RECEIVED  TRANSACTION  - OTHER  FUNDING 

****  REIMBURSABLE  ALLOTMENT  RECEIVED  TRANSACTION  - RSPM  FUNDING 

****  REIMBURSABLE  ALLOTMENT  RECEIVED  TRANSACTION  - RSD  FUNDING 

****  REIMBURSABLE  ALLOTMENT  RECEIVED  TRANSACTION  - C OF  F FUNDING 

****  REIMBURSABLE  ALLOTMENT  RECEIVED  TRANSACTION  - OTHER  FUNDING 

****  RSPM  ALLOTMENT  TRANSFERRED  TRANSACTION 

****  SUB  ISSUED  TRANSACTION  - RSFM  FUNDING 

****  SUB  ISSUED  TRANSACTION  - RSD  FUNDING 

****  SUB  ISSUED  TRANSACTION  - C of  F FUNDING 

****  SUB  ISSUED  TRANSACTION  - OTHER  FUNDING 

B0 1 0 TYPE  OF  TRANSACTION  NOT  SPECIFIED 

B0 1 1 MULTIPLE  TYPES  OF  TRANSACTIONS  SPECIFIED 

B 020  TYPE  OF  FUNDING  NOT  SPECIFIED 

B021  MULTIPLE  TYPES  OF  FUNDING  SPECIFIED 

B 022  TYPE  OF  FUNDING  SHOULD  NOT  BE  SPECIFIED 


Figure  7- • 3-5 . - Allotment  transaction-begun  messages 


Code 


Message 


A 000  PROCESSING  COMPLETE 
A110  ALLOTMENT  RESULTS: 

MA PY FS 

OLD  RECEIPTS  , , • UPDATE  $_» , «., — • — * 

NEW  RECEIPTS  , 

A 1 1 1 ALLOTMENT  RESULTS: 

MA  __  PY  __  FS  __ 

OLD  RECEIPTS  , , . ISSUES  , , • — 

UPDATE  RECEIPTS  • ± ISSUES  r » 

NEW  RECEIPTS  , , • ISSUES  , r • — 

SUB  ISSUED  SUSPENSE  RESULTS: 

HA PY FS  SOB  ID  

OLD  BALANCE  t , ■ t UPDATE  — , » • — ± 

NEW  BALANCE  , , • __± 


Figure  2.3-6.  - Allotment  transaction-complete  messages. 
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2~ 


Code 


B 1 00  'AS  OF*  DATE  INVALID 

B101  'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE / /. 

Bl 1 0 MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 1 3 MA  MOST  BE  10  TO  79 

B 1 1 6 MA  MOST  BE  00  OR  10  TO  79 

Bl 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

Bl 30  FS  NOT  ENTERED 

B 1 35  FS  MOST  BE  1,  4,  OR  5 

Bl 36  FS  MOST  BE  R6PM  FOND  SOORCE 

Bl 60  SOB  ID  NOT  ENTERED 

B161  SOB  ID  INVALID 

B 1 62  SOB  ID  MOST  BE  10  TO  79 

B600  $ AMOONT  NOT  ENTERED 

B601  $ AMOONT  INVALID 

B602  $ AMOONT  MOST  NOT  BE  ZERO 

B920  AMENDMENT  NOMBER  NOT  ENTERED 

B921  AMENDMENT  NOMBER  INVALID 

B922  AMENDMENT  NOMBER  MOST  BE  GREATER  THAN  ZERO 
C501  MA  , PY,  FS  COMBINATION  INVALID 
C502  FS  MOST  BE  A FONDING  FOND  SOORCE 


Figure  2.3-7.  - Allotment  data  element  edit  error  messages. 


Code 


&£§§&as 


D 1 10  ALLOTMENT  RECORD  NOT  FOUND 

MA PY FS PNC  

Dill  ALLOTMENT  BALANCE  INSUFFICIENT  TO  DECREASE  RECEIPTS 

MA PY FS  __  PNC  

BALANCE  $_, , , • UPDATE  $_, , , . — - 

D 1 12  ALLOTMENT  ISSUES  INSUFFICIENT 

MA PY FS PNC  

ISSUES  , , . UPDATE  $_, , , • — - 

D120  REIMBURSABLE  SUSPENSE  RECORD  NOT  FOUND 
MA PY FS  __ 

D 1 21  REIMBURSABLE  SUSPENSE  BALANCE  INSUFFICIENT  TO  DECREASE  RECEIPTS 
MA  ' __  FS  __ 

BALANCE  , , UPDATE  $_, , , • — ” 

D1 30  SUB  ISSUED  SUSPENSE  RECORD  NOT  FOUND 

MA PY FS SUB  ID 

D131  SUB  ISSUED  SUSPENSE  ISSUES  INSUFFICIENT 
MA PY FS  __  SUB  ID  

ISSUES  , . UPDATE  , , . — " 


Figure  2.3-8.  - Allotment  processing  error  messages. 
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Message 

A 

A 

A 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

c 

c 

D 

D 

D 

D 

D 

D 

D 

0 

1 

1 

0 

0 

0 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

6 

6 

6 

9 

9 

9 

5 

5 

1 

1 

1 

1 

1 

1 

1 

0 

1 

1 

1 

1 

2 

2 

2 

0 

0 

1 

1 

1 

1 

2 

2 

2 

3 

3 

3 

6 

6 

6 

0 

0 

0 

2 

2 

2 

0 

0 

1 

1 

1 

2 

2 

3 

3 

Transaction 

0 

0 

1 

0 

1 

0 

1 

2 

0 

1 

0 

1 

3 

6 

0 

1 

2 

0 

5 

6 

0 

1 

2 

0 

1 

2 

0 

1 

2 

1 

2 

0 

1 

2 

0 

1 

0 

1 

Direct  Allotment 

' 

Received 

R&PM  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

R&D  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

C of  F funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Other  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Allotment.  Received 

R&PM  funding 

X 

X 

X 

V 

A 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

R&D  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

C of  F funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Other  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Reimbursable ^Allotment 

Received 

R&PM  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

R&D  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

C of  F funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Other  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

R&PM  Allotment 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Transferred 

Sub  Issued 

R&PM  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

R&D  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

C of  F funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Other  funding 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Figure  2.3-9 


Allotment  messages  by  transaction 


Inquiry  description 


Allotment  Fund  Control 
status  by  Fund  Source 


Sub  Issued  Fund 
Control  status 


Allotment  Fund  Control 
summary  by  appropriation 


ro  Allotment  Fund  Control 

L summary  by  Program  Tear 


Allotment  Fund  Control 
summary  by  Method  of 
Authority 


Allotment  grand  total 


Allotment  Fund  Control 
total  by  Method  of 
Authority  and  appro- 
priation 

Allotment  Fund  Control 
total  by  Program  Year 
and  appropriation 


Type 

Item 

Input  data  elements 

Timinq 

Response  data  elements 

Method  of  Authority 
Program  Year 
Fund  Source  (funding 
level) 

Immediate 

Method  of  Authority 
Program  Year 
Funding  Fund  Source 
Allotment  receipts 
Allotment  issues 
Allotment  balance 

Last  receipts  activity  information 
Last  issues  activity  information 

Item 

Program  Year 
Fund  Source  appro- 
priation 

Subauthorization 

Identifier 

Immediate 

Program  Year 

Fund  Source  (appropriation) 
Subauthorization  Identifier 
Sub  Issued  Suspense  receipts 
Sub  Issued  Suspense  issues 
Sub  Issued  Suspense  Balance 

Summary 

Method  of  Authority 
Program  Year 
Appropriation  type 

Immediate 

Method  of  Authority 
Program  Year 
Appropriation  symbol 
Allotment  receipts 
Allotment  issues 
Allotment  balance 

Summary 

Method  of  Authority 
Program  Year 

Immediate 

Method  of  Authority 
Program  Year 
Allotment  receipts 
Allotment  issues 
Allotment  balance 

Summary 

Method  of  Authority 

Immediate 

Method  of  Authority 
Appropriation  symbol 
Allotment  receipts 
Allotment  issues 
Allotment  balance 

Summary 

None  required 

Immediate 

Allotment  receipts 
Allotment  issues 
Allotment  balance 

Summary 

Method  of  Authority 
Appropriation  type 

Immediate 

Method  of  Authority 
Appropriation  symbol 
Allotment  receipts 
Allotment  issues 
Allotment  balance 

Summary 

Program  Year 
Appropriation  type 

Immediate 

Program  Year 
Appropriation  symbol 
Allotment  receipts 
Allotment  issues 
Allotment  balance 

Figure  2.3-10.  - Allotment  inquiry  requirements 


Inquiry  descriptio n 


Allotment  Fund  Control 
total  by  appropriation 


Resources  Authority/ 
Allotment  summary 
by  appropriation 


Resources  Authority/ 
Allotment  total  by  Program 
Year  ana  appropriation 


Type  Input  data  elements  Timing 

Summary  Appropriation  type  Immediate 


Summary  Method  of  Authority  Immediate 

Program  Year 
Appropriation  type 


Summary  Program  Year 

Appropriation  type 


Immediate 


Response  data  elements 


Appropriation  symbol 
Allotment  receipts 
Allotment  issues 
Allotment  balance 

Program  Year 
Method  of  Authority 
Appropriation  symbol 
Resources  Authority  receipts 
Sub  Issued  receipts 
Available  receipts 
Allotment  receipts 
Sub-Allotment  receipts 
Sub  Issued  Suspense  balance 
Available  receipts 

Resources  Authority/Allotment  available 
receipts  difference 

Program  Year 
Method  of  Authority 
Appropriation  symbol 
Resources  Authority  receipts 
Sub  Issued  receipts 
Available  receipts 
Allotment  receipts 
Sub-Allotment  receipts 
Sub  Issued  Suspense  balance 
Available  receipts 

Resources  Authority/Allotment  available 
receipts  difference 


Figure  2.3-10.  - Allotment  inquiry  requirements  (concluded). 


2.4  PRIMARY  WORK  AUTHORIZATION  PROCESS 


The  PWA  is  the  method  used  by  the  JSC  budget  officers 
to  reserve  RA  and  Allotment  for  specific  projects  and 
activities  based  on  the  JSC  POP.  When  the  PWA  allocation  of 
funds  is  made,  additional  funds  controlling  elements  are 
added  based  on  the  appropriation  type.  All  R&PM  funds  are 
given  a funding  Object  Class  when  current  year  funds  are 
being  allocated.  Allocation  of  prior  year  funds  to  the  PWA 
receive  no  Object  Class  because  R&PM  funds  are  single  year 
funds  and  no  Object  Class  distinction  is  retained  for  those 
funds.  R&D  and  C of  F funds  are  assigned  sufficient 

additional  PWC  digits  to  control  PWA  funds  at  the  five-digit 
PWC.  The  PWA  allocation  of  reimbursable  funds  and 
subauthorizations  issued  to  other  centers  is  at  the  nine- 
digit PWC. 

PWA's  are  categorized  into  the  following  three  types: 

• Conventional  PWA  - An  action  reserving  RA  and 

Allotment  for  specific  programs  or  activities  and 
assigning  the  funds  to  JSC  organizations  permitted 
to  receive  PWA  funds  assignments.  These 

organizations  and  other  organizations  reporting  to 
them  can  begin  commitment,  obligation,  and 

expenditure  actions  against  these  funds  for  the 

projects  or  activities  specified  if  the  organization 
code  has  been  validated  as  one  permitted  to  commit 
funds. 

• Reservation  PWA  - An  action  reserving  RA  and 

Allotment  by  project  or  activity  and  organization 
for  use  in  the  funding  of  a Carrier  account.  The 
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action  specified  the  Carrier  account  receiving  these 
funds.  The  Reservation  PWA  action  is  also  used  in  a 
special  case  to  reserve  funds  of  one  Carrier  account 
to  fund  another  Carrier  account.  In  this  instance, 
no  additional  reservation  of  RA  and  Allotment  is 
required. 

• Sub-RA  PWA  - An  action  reserving  RA  and  Allotment  by 
project  or  activity  for  issuance  of  a Sub-RA  to 
another  NASA  center  for  work  in  support  of  JSC 
projects.  A Resources  Authority  Warrant  is  sent 
from  JSC  to  the  receiving  center  with  a copy  to  NASA 
Headquarters.  NASA  Headquarters  then  withdraws 
allotment  from  JSC  in  the  amount  of  the  Sub-RA 
issued  and  sends  that  amount  to  the  receiving 
center. 


2.4.1  Update  Requirements 

PWA  actions  are  begun  in  the  responsible  JSC  budget 
office  and  are  transmitted  to  FMD  via  the  Primary  Work 
Authorization  (JSC  Form  2233) . This  form  is  received  by  the 
Central  Resources  Section  where  the  information  is  to  be 
entered  into  the  online  system.  The  dollar  amounts  of  PWA's 
must  update  the  receipts  of  the  Conventional  PWA  account, 
the  Reservation  PWA  account,  or  the  Sub-RA  PWA  account 
according  to  the  type  of  PWA  action  specified. 

A separate  transaction  is  defined  for  the  input  of  each 
of  the  three  PWA  types  defined  in  the  previous  paragraphs. 
Input,  processing,  and  output  requirements  will  be  discussed 
by  transaction. 


2. 4. 1.1  Conventional PWA.  Reservation  of  RA  and 

Allotment  under  a Conventional  PWA  action  is  to  be  recorded 
as  a Conventional  PWA  transaction.  Commitment,  obligation, 
and  expenditure  of  these  funds  are  permitted  for  RO's 
validated  as  ones  permitted  to  perform  such  actions. 

IHESt  ~ Figure  2.4-1  contains  a list  of  the  elements 
that  must  be  input  for  the  Conventional  PWA  transaction. 
The  template  used  for  input  of  this  and  all  other  PWA 
transactions  is  shown  in  figure  2.4-2. 

Processing  - Because  RA  and  Allotment  are  the  limiting 
controls  of  all  Conventional  PWA  actions,  applicable  RA  and 
Allotment  subaccount  entries  must  be  referenced. 

The  applicable  RA  subaccount  and  the  funding  entry  are 
determined  by  MA  (identifying  the  Direct,  Sub-RA  Received, 
or  Reimbursable  subaccounts) , PY,  and  FS  for  all 
appropriation  types.  The  FS  input  for  PWA  action  must  be 
converted  from  the  PWA  FS  to  the  applicable  RA  FS.  In 
addition,  all  R&D  activities  require  the  first  three  digits 
of  the  PWC  input  to  the  transaction,  and  the  C of  F 
activities  require  the  first  four  digits  to  identify  the 
proper  subaccount  entry.  The  Allotment  subaccount  and  its 
funding  entry  are  determined  by  MA,  PY , and  funding  level 
FS.  The  FS  input  must  be  converted  to  the  applicable 
funding  level  FS. 

A positive  dollar  amount  requires  both  RA  and 
Allotment  subaccount  entries  to  have  sufficient  balance  to 
fund  the  action  requested  by  this  transaction.  The  posting 
must  result  in  an  increase  to  the  applicable  RA  and 


Data 

element 


Element 

required 


Source 


• AS  Of 
Date 


Method  of 
Authority 


Program  Year 


Fund  Source 


Primary  Work 
Code 


Object  Class 


Pesponsible 

Organization 

Dollar 

Amount 


Control 

Humber 


Type  of 
transaction 

Correction 


Error 


tIEe_ 


Error 

code_ 


Optional 

U ser 

supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  num- 
eric and  conform  to  all  normal  date  edits. 

B 1 00 
B101 

Yes 

Form  2233 

Falsi 

Input  for  all  Conventional  PWA  transactions. 
Must  be  a valid  MA  but  not  97. 

B100 
Bill 
B 1 1 5 

Yes 

Form  2233 

Fatal 

Input  for  all  Conventional  PWA  transactions. 
Must  be  a valid  PY.  Also  validated  with  FS. 

B 1 20 
B 1 21 

Yes 

Form  2233 

Fatal 

Input  for  all  Conventional  PWA  Distributed  trans- 
actions. Must  be  in  the  range  1 through  9 or  11. 
Also  validated  with  PY. 

B 1 30 
C500 

Conditional 

Form  2233 

Fatal 

Input  as  follows  for  all  Conventional  PWA  Distri- 
buted transactions  depending  on  the  values  of  MA 
and  FS  as  specified  on  the  template: 

B170 

B171 

B174 

B175 

MA  IS  Input/Edit 

Direct,  Sub-RA  Received  1-3  None  _ # 

Direct,  Sub-RA  Received  4-9,11  Five-digit  PWC 
Reimbursable  Any  Nine-digit  PWC 

B176 

C500 

Conditional 

Form  2233 

Fatal 

Input  as  follows  for  all  Conventional  PWA  trans- 
actions depending  on  the  value  of  FS  any  PY  as 
specified  on  the  template: 

B190 
B 1 91 

dv  Input  Edit 

1Z3  Current  year  Humeric,  specific  values 

j-3  Prior  year  None 

4-9, X Any  year  None 

The  Object  Class  input  must  be  a funding  Object 
Class. 

Yes 

Form  2233 

Fatal 

Input  for  all  Conventional  PWA  transactions. 
Must  be  a valid  funding  RO. 

B200 

B201 

Yes 

Form  2233 

Fatal 

Input  for  all  Conventional  PWA  transactions. 
Must  be  numeric  and  not  egual  to  0. 

B600 

B601 

B602 

Yes 

User 

supplied 

Fatal 

Identification  number  of  PWA  source  document. 
Input  for  all  Conventional  PWA  transactions. 
Must  be  numeric  and  greater  than  0- 

B910 

B911 

B912 

Yes 

Optional 

User 

supplied 

User 

supplied 

Fatal 

Hone 

Transaction  indicator.  Input  as  a Conventional 
PWA  transaction. 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction. 

B0 1 0 
B0 1 1 

None 

Figure  2.4-1.  - Conventional  Primary  Work  Authorization  input  and  edit  requirements. 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / 

****TEMPLATE  HO.  HI  - PWA 

MA PY FS PWC  OBJECT  CLASS 

RESP  ORG PWA  $ , , . ± CONTROL  NO. 

TYPE  OF  TRANSACTION: 

CON V PWA 

RESERVATION  PWA  _ CARRIER  RESP  ORG  CARRIER  ID 

SUB-RA  PWA 
CORRECTION 


Figure  2.4-2.  - Primary  Work  Authorization  template. 
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Allotment  subaccount  entry  issues  (both  already  defined  in 
the  data  base)  and  an  increase  to  the  Conventional  PWA 
account  entry  receipts.  The  Conventional  PWA  account  entry 
applicable  is  identified  for  all  Direct  and  Sub-RA  Received 
activity  by  MAr  PY,  FSr  RO,  and  funding  level  Object  Class 
for  R&PM  appropriation  activity  or  a five-digit  PWC  for  R&D 
and  C of  F appropriations.  Reimbursable  order  activity  is 
identified  by  these  same  elements  and  a nine-digit  PWC 
regardless  of  appropriation  type.  If  the  Conventional  PWA 
account  entry  does  not  already  exist  in  the  data  base,  it  is 
generated  with  the  following  elements: 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Responsible  Organization  (designated  to  receive  PWA 
funds) 

• Object  Class  (R&PM  appropriation  only) 

• Primary  Work  Code  (five  digits  for  R&D  and  C of  F 
appropriations;  nine  digits  for  all  reimbursable 
orders  regardless  of  appropriation) 

• Dollar  Amount  (receipts) 

A negative  dollar  amount  in  this  transaction  must 
result  in  the  posting  of  a decrease  to  the  Conventional  PWA 
account  entry  receipts  and  a like  decrease  to  the  RA  and 
Allotment  subaccount  entry  issues  funding  PWA  action.  A 
negative  balance  must  not  occur  in  any  of  the  defined 
subaccount  entries. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
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Initial  input  and  correction  transactions  will  be  identified 
in  the  transaction  history. 

Output  - Section  2.4.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Conventional  PWA  transaction. 

2.4. 1.2  Reservation PWA.  Reservation  of  funds  to  be 

assigned  to  a Carrier  account  under  a Reservation  PWA  action 
is  to  be  recorded  as  a Reservation  PWA  transaction.  RA  and 
Allotment  are  reserved  through  this  transaction,  assigned  to 
an  RO  funding  the  Carrier  account,  and  issued  to  that 
Carrier  account. 

“ The  Reservation  PWA  transaction  uses  the  PWA 
template  defined  for  all  PWA  transactions.  This  template  is 
shown  in  figure  2.4-2*  Figure  2.4-3  contains  a list  of  the 
elements  that  must  be  input  for  all  Reservation  PWA 
transactions. 

“ The  Reservation  PWA  transaction  must 
reference  the  applicable  RA  and  Allotment  subaccount  entries 
to  obtain  the  funds  required  in  the  transaction. 

The  RA  subaccount  and  the  funding  entry  required  for 
the  Reservation  PWA  are  determined  by  MA  (identifying  the 
Direct,  Sub-RA  Received,  or  Reimbursable  subaccounts) , PY, 
and  FS  for  all  appropriation  types.  The  FS  input  for  PWA 
action  must  be  converted  from  the  PWA  FS  to  the  applicable 
RA  FS.  In  addition,  all  R&D  activities  require  the  first 
three  digits  of  the  PWC  that  are  input  to  the  transaction, 
and  C of  F activities  require  the  first  four  digits  to 


Data 

element 

Element 

required 

Source 

Error 
t ype_ 

'As  of* 
Date 

Optional 

User 

supplied 

Fatal 

Method  of 
Authority 

Yes 

Form  2233 

Fatal 

Program  Year 

Yes 

Form  2233 

Fatal 

Fund  source 

Yes 

Form  2233 

Fatr 

Primary  Work 
Code 

Conditional 

Form  2233 

Fatal 

Object  class 

Conditional 

Form  2233 

Fatal 

Responsible 

Organization 

Yes 

Form  2233 

Fatal 

Dollar 

Amount 

Yes 

Form  2233 

Fatal 

Type  of 
transaction 

Yes 

User 

supplied 

Fatal 

carrier 

Responsible 

Organization 

Yes 

User 

supplied 

Fatal 

Carrier 

Identifier 

Yes 

Form  2233 

Fatal 

Correction 

Optional 

User 

supplied 

None 

Control 

Number 

Yes 

User 

supplied 

Fatal 

Tnput/Edit  requirements 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  «dits. 

Input  for  all  Reservation  PWA  transactions.  Hust 
be  a valid  HA  but  not  97. 


Input  for  all  Reservation  PWA  transactions,  Hust 
be  a valid  PY.  Also  validated  with  FS. 


Input  for  all  Reservation  PWA  transactions.  Hust 
be  either  11  or  in  the  range  1 through  9.  Also 
validated  with  PY. 


Input  as  follows  for  all  Reservation  PWA  trans- 
actions depending  on  the  values  of  KA  and  FS  as 
specified  on  the  template: 


HA 

Direct,  Sub-RA  Received 
Direct,  Sub-RA  Received 
Reimbursable 


FS  Input/Edit 

1-3  None 

4-9,11  Five-digit  PWC 
Any  Nine-digit  PWC 


Input  as  follows  for  all  Reservation  PWA  trans- 
actions depending  on  the  values  of  rS  and  PY  as 


FS 

py 

Numeric 

1-3 

Current  Year 

1-3 

Prior  Year 

None 

4-9, X 

Any  year 

None 

Input  Edit 
, specific 


values 


Input  for  all  Reservation  PWA  transactions.  Must 
be  a valid  funding  RO. 


Input  for  all  Reservation  PWA  transactions.  Must 
be  numeric  and  not  egual  to  0. 


Transaction  indicator.  Input  as  a Reservation 
PWA  transaction. 

Input  for  all  Reservation  PWA  transactions.  Must 
be  a valid  RO. 


Input  for  all  Reservation  PWA  transactions, 
be  numeric  and  a valid  Carrier  Identifier. 

Transaction  codifier  indicating  that  the  trans- 
action  is  a correction.  Input  only  when  the 


Must 


Identification  number  of  PWA  source  document. 
Input  for  all  Reservation  PWA  transactions.  Hust 


Figure  2.4-3.  - Reservation  Primary  Work  Authorization  input  and  edit  requirements. 


Error 

code 

B 1 00 
B 1 01 


El  10 
Bill 
B115 
B117 

B120 

B121 

B123 

C500 

B130 

F131 

1138 

-C500 

B170 
E 171 
B174 
£175 
B176 


B190 

B191 

B192 


* B200 
B201 

B600 

B601 

B602 

B0 1 0 
B011 

B210 

B211 


B150 
El  51 

None 


B910 
B91 1 
B912 


identify  the  proper  subaccount  entry.  The  Allotment 
subaccount  and  its  funding  entry  are  determined  by  MA,  PY, 
and  funding  level  FS.  The  FS  input  to  the  transaction  must 
be  converted  to  the  applicable  funding  level  FS. 

A positive  dollar  amount  requires  both  HA  and 
Allotment  subaccount  entries  to  have  sufficient  balance  to 
fund  the  action  requested  by  the  Reservation  PWA 
transaction.  The  posting  must  result  in  an  increase  to  the 
applicable  RA  and  Allotment  subaccount  entry  issues  (both 
already  defined  in  the  data  base) , an  increase  to  the 
Reservation  PWA  account  entry  receipts,  and  an  increase  to 
the  designated  Carrier  account  receipts.  The  Reservation 
PWA  account  entry  applicable  is  identified  for  Direct  and 
Sub-RA  Received  activity  by  MA v PY  , FS,  RO,  and  funding 
level  Object  Class  for  R&PM  appropriation  activity  or  a 
five-digit'  PWC  for  R&D  and  C of  F appropriations. 
Reimbursable  order  activity  is  identified  by  these  same 
elements  and  a nine-digit  PWC  regardless  of  appropriation 
type.  If  the  Reservation  account  entry  does  not  already 
exist  in  the  data  base,  it  is  generated  with  the  following 
elements: 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Responsible  organization  (designated  to  receive 
PWA  funds) 

• Object  Class  (R&PM  appropriation  only) 

• Primary  Work  Code  (five  digits  for  R&D  and  C of  F 
appropriations;  nine-digits  for  all  reimbursable 
orders  regardless  of  appropriation) 


• Carrier  Identifier 

• Dollar  Amount  (receipts) 

The  designated  Carrier  account  receiving  the  reservation 
funds  is  identified  by  MA,  PY,  FS,  RO,  and  Carrier 
Identifier.  If  the  account  does  not  already  exist  in  the 
data  base,  it  is  generated  with  the  following  elements: 

• Method  of  Authority  (must  be  00) 

• Program  Year  (must  be  current  program  year) 

• Fund  Source  (must  be  9) 

• Responsible  organization  (designated  as  the  Carrier 
account  owner) 

• Carrier  Identifier 

• Dollar  Amount  (receipts) 

A negative  dollar  amount  in  the  Reservation  PWA 
transaction  must  result  in  the  posting  of  a decrease  to  the 
Reservation  PWA  account  entry  receipts,  a like  decrease  to 
the  Carrier  account  receipts,  and  a like  decrease  to  the  RA 
and  Allotment  subaccount  entry  issues  originally  funding  the 
action.  A negative  balance  must  not  occur  in  any  of  the 
defined  account/subaccount  entries* 


To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  input  and  correction  transactions  will  be  identified 
in  the  transaction  history. 

Output  - Section  2.4.2  describes  the  standard  online 
responses  ana  error  messages  that  are  required  in  the 
processing  of  a Reservation  PWA  transaction. 
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2. 4. 1.3  Sub-RA PWA.  Reservation  of  RA  and  Allotment 

under  a Sub-RA  PWA  action  is  to  be  recorded  as  a Sub-RA  PWA 
transaction.  Funds  reserved  by  this  transaction  are 
assigned  to  the  RO  having  the  controlling  authority  for  the 
program  work  being  issued  on  a Sub-RA,  and  the  funds  are 
assigned  the  Subauthorization  Identifier  of  the  center  to 
receive  the  Sub-RA  issues* 

The  Sub-RA  PWA  is  the  first  step  of  the  two  step 
process  required  to  record  the  issuance  of  RA  to  another 
NASA  Center  for  work  in  support  of  JSC.  The  Sub-RA  PWA 
action  reserves  the  JSC  allotment  that  will  be  subsequently 
withdrawn  by  NASA  Headquarters  as  a Sub-Allotment 
transaction  (the  second  step  required  in  this  process).  The 
Sub  Issued  Suspense  account  is  used  to  record  outstanding 
Sub-RA  PWA  until  the  allotment  is  withdrawn. 

- Figure  2.4-4  contains  a list  of  the  elements 
that  must  be  input  and  the  edits  that  must  be  performed  for 
the  Sub-RA  PWA  transaction.  The  template  used  for  input  of 
this  and  all  other  PWA  transactions  is  shown  in  figure  2.4- 

2. 


Processing  - Because  RA  and  Allotment  are  the  limiting 
controls  of  all  Sub-RA  PWA  actions,  applicable  RA  and 
Allotment  subaccount  entries  must  be  referenced.  The 
applicable  RA  subaccount  and  the  funding  entry  are 
determined  by  HA  (must  be  Direct)  PY,  and  FS  for  all 
appropriation  types.  The  FS  input  for  PWA  action  must  be 
converted  from  the  PWA  FS  to  the  applicable  RA  FS.  In 
addition,  all  R&D  activities  require  the  first  three  digits 
of  the  PWC,  and  C of  F activities  require  the  first  four 
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Data  Element  Error 

element  required  Source  type 


•As  of* 
Date 

Optional 

User 

supplied 

Fatal 

Method  of 
Authority 

Yes 

Form  2233 

Fatal 

Program  Year 

Yes 

Form.  2233 

Fatal 

Fund  Source 

Yes 

Form  2233 

Fatal 

Primary  Work 
Code 

Yes 

Form  2233 

Fatal 

Object  Class 

No 

None 

Fatal 

Dollar 

Amount 

Yes 

PWA 

Fatal 

Type  of 
transaction 

Yes 

User 

supplied 

Fatal 

Responsible 

Organization 

Yes 

PWA 

Fatal 

Sub- 

authorization 

Identifier 

Yes 

Form  2233 

Fatal 

Correction 

Optional 

User 

supplied 

None 

Control 

Number 

Yes 

User 

supplied 

Fatal 

Error 

Input/Edit  requirements  code 


Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  mast  be 
numeric  and  conform  to  all  normal*  date  edits. 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B110 

equal  to  00.  B117 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B120 

a valid  PY.  Also  validated  with  FS.  B121 

C500 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B130 

in  the  range  1 through  9 or  11.  Also  B131 

validated  with  PY.  C500 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B170 

nine  digits.  B171 

3174 

C500 

Must  not  be  input  for  any  Sub-RA  PRA  transaction.  B192 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B600 

numeric  and  not  equal  to  0.  B601 

B602 

Transaction  indicator.  Input  as  a Sub-RA  PWA  B010 

transaction.  B011 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B200 

a valid  funding  RO. 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B160 

numeric  and  in  the  range  10  through  79.  B161 

B 1 62 

Transaction  modifier  indicating  that  the  trans-  None 

action  Is  a correction.  Input  only  when  the 
transaction  is  a correction. 

Input  for  all  Sub-RA  PWA  transactions.  Must  be  B910 

numeric  and  greater  than  0.  B911 

B912 


Figure  2.4-4.  - Sub-RA  Primary  Work  Authorization  input  and  edit  requirements. 


digits  to  identify  the  proper  subaccount  entry.  Because  the 
Sub-RA  must  be  input  to  the  transaction  at  the  five-digit 
level  for  use  in  this  transaction.  The  Allotment  subaccount 
and  its  funding  entry  are  determined  by  MA,  PY,  and  funding 
level  FS.  The  FS  input  to  the  transaction  must  be  converted 
to  the  applicable  funding  level  FS. 

A positive  dollar  amount  requires  both  RA  and  Allotment 
subaccount  entries  to  have  sufficient  balance  to  fund  the 
action  requested  by  the  Sub-RA  PWA  transaction.  The  posting 
must  result  in  an  increase  to  the  applicable  RA  and 
Allotment  subaccount  entry  issues  (both  already  defined  in 
the  data  base) , an  increase  to  the  Sub-RA  PWA  account  entry 
receipts,  and  an  increase  to  the  Sub  Issued  Suspense  account 
entry  receipts.  If  the  unrecorded  commitments  field  of  the 
Sub-RA  PWA  account  entry  is  greater  than  0,  the  transaction 
dollar  amount  must  be  used  to  reduce  those  unrecorded 
commitments.  If  the  transaction  dollar  amount  is  greater 
than  or  equal  to  the  unrecorded  commitments,  the  unrecorded 
commitments  are  reduced  to  0.  Otherwise,  the  unrecorded 
commitments  are  reduced  by  the  transaction  dollar  amount. 
The  amount  by  which  the  unrecorded  commitments  are  reduced 
must  be  added  to  the  Sub-RA  PWA  account  entry  issues.  The 
Sub-RA  PWA  account  entry  applicable  is  identified  by  MA,  PY, 
FS,  RO,  and  subauthorization  Identifier  for  all 
appropriations.  In  addition,  a five— digit  PWC  is  required 
for  R&D  and  C of  F appropriations.  If  the  Sub-RA  PWA  account 
entry  does  not  already  exist  in  the  data  base,  it  is 
generated  with  the  following  data  elements: 

• Method  of  Authority 

• Program  Year 


• Fund  Source 

• Responsible  Organization 

• Primary  Work  Code  (headquarters  five-digit  Primary 
Work  Code)  for  R&D  and  C of  F appropriations  only) 

• Subauthorization  Identifier 

• Dollar  Amount  (receipts) 

The  Sub  Issued  Suspense  account  entry  applicable  is 
identified  by  MA,  PY,  appropriation  level  FS,  and 
Subauthorization  Identifier.  The  input  FS  must  be  converted 
to  the  appropriation  level  FS.  If  the  Sub  Issued  Suspense 
account  entry  does  not  already  exist  in  the  data  base,  it  is 
generated  with  the  following  data  elements: 

• Method  of  Authority 

• Program  Year 

• Fund  Source  (appropriation  level) 

• Subauthorization  Identifier 

• Dollar  Amount  (receipts) 

The  positive  dollar  amount  in  the  Sub-RA  PWA 
transaction  also  requires  that  basic  information  required 
for  the  recording  of  the  subauthorization  performance  data 
be  recorded  in  the  data  base  at  the  time  of  this 
transaction.  The  applicable  Subauthorization  performance 
data  is  identified  by  MA,  PY,  FS,  a nine-digit  PWC 
(headquarters  coding)  and  Subauthorization  Identifier.  If 
the  performance  data  already  exists  in  the  data  base,  the 
input  RO  must  match  the  RO  recorded  in  the  performance  data 
record.  Otherwise,  all  updating  stops,  and  an  error  message 
is  provided.  If  the  RO's  do  match,  the  dollar  amount 
updates  the  Subauthorization  performance  dollars  maintained 
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in  the  performance  data  record.  If  the  Subauthorization 
performance  data  does  not  already  exist,  it  is  generated 
with  the  following  elements: 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Responsible  Organization 

• Nine-digit  Primary  Work  Code 

• Subauthorization  Identifier 

• Dollar  Amount  (Subauthorization  performance  dollars) 

A negative  dollar  amount  in  the  Sub-EA  PWA  transaction 
must  result  in  the  posting  of  a decrease  to  the  Sub-RA  PWA 
account  entry  receipts,  a decrease  to  the  Sub  Issues 
Suspense  account  entry  receipts,  a decrease  to  the  RA  and 
Allotment  subaccount  entry  issues,  and  a decrease  to  the 
Subauthorization  performance  dollars.  A negative  balance 
must  not  occur  in  any  of  the  defined  account/subaccount 
entries,  and  the  Subauthorization  dollars  must  not  be  less 
than  0.  A warning  must  be  given  if  the  Subauthorization 
performance  dollars  are  reduced  below  the  Subauthorization 
performance  commitment  dollars  recorded. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  input,  update,  and  correction  transactions  will  be 
identified  in  the  transaction  history. 

OaiEJJt  _ Section  2.4.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Sub-RA  PWA  transaction. 


2.4.2  Output  Message  Requirements 

Figures  2.4-5  through  2*4-8  contain  a list  of  output 
message  requirements.  Figure  2.4-9  contains  a correlation 
of  output  messages  by  transaction. 

2.4.3  Inquiry  Requirements 

Figure  2.4-10  contains  a list  of  inquiry  input  data 
elements  and  response  data  elements  required  for  PWA 
processing. 

2.4.4  Report  Requirements 

Section  2.19.1  lists  the  Fund  Control  Report 
requirements.  The  following  reports  reflect  PWA  account 
activity: 

• PWA  Fund  Control  Status 

• PWA  RO  Fund  Control  Status 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  PWA  Section  report  described  in 
section  2.19.7. 
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M§§§aa§ 


Code 

****  CONVENTIONAL  PW  A TRANSACTION 

****  RESERVATION  PWA  TRANSACTION 

****  SOB-RA  PHA  TRANSACTION 

B010  TYPE  OF  TRANSACTION  NOT  SPECIFIED 

B01 1 MULTIPLE  TYPES  OF  TRANSACTIONS  SPECIFIED 

Figure  2.4-5.  - Primary  Work  Authorization 
transaction-begun  messages . 


Code  Message 

A000  PROCESSING  COMPLETE 


Figure  2.4-6.  - Primary  Work  Authorization 
transaction-complete  messages. 


Message 


Code 


B100  'AS  OF'  DATE  INVALID 

p 1 01  'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE / /. 

B1 10  MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 1 5 MUST  NOT  BE  97 

B 1 17  MA  MUST  BE  00 

B 1 20  PY  NOT  ENTERED 

B121  PY  INVALID 

B1 30  FS  NOT  ENTERED 

B 131  FS  MUST  BE  1-9  OR  11 

B1 38  FS  MUST  BE  9 

B1 50  CARRIER  ID  NOT  ENTERED 

B 1 51  CARRIER  ID  INVALID 

B 1 60  SUB  ID  NOT  ENTERED 

B 1 6 1 SUB  ID  INVALID 

B 1 62  SUB  ID  MUST  BE  10  TO  79 

B170  PWC  NOT  ENTERED 

B 1 7 1 PWC  INVALID 

B 1 74  PWC  MUST  BE  9 DIGITS 

B 1 7 5 PWC  MUST  BE  BLANK 

B 1 76  PWC  MUST  BE  5 DIGITS 

B 1 90  OBJECT  CLASS  NOT  ENTERED 

B 1 9 1 OBJECT  CLASS  INVALID 

B 1 92  OBJECT  CLASS  MUST  BE  BLANK 

B200  RESPONSIBLE  ORGANIZATION  NOT  ENTERED 

B201  RESPONSIBLE  ORGANIZATION  INVALID 

B210  CARRIER  RESPONSIBLE  ORGANIZATION  NOT  ENTERED 

B2 1 1 CARRIER  RESPONSIBLE  ORGANIZATION  INVALID 

B600  $ AMOUNT  NOT  ENTERED 

B601  $ AMOUNT  INVALID 

B602  $ AMOUNT  MUST  NOT  BE  ZERO 

B910  CONTROL  NUMBER  NOT  ENTERED 

B911  CONTROL  NUMBER  INVALID 

B912  CONTROL  NUMBER  MUST  BE  GREATER  THAN  ZERO 
C500  PY,  FS  COMBINATION  INVALID 

Figure  2.4-7.  - Primary  Work  Authorization 
data  element  edit  error  messages. 
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Code  Message 

D 1 00  RESOURCES  AUTHORITY  RECORD  NOT  FOUND 

MA  __  PY  __  F5  _ PWC  

D 1 02  RESOURCES  AUTHORITY  ISSUES  INSUFFICIENT 
MA  __  PY FS  _ PWC 

ISSUES  $ _ , , , • UPDATE  , r • — " 

D 1 03  RESOURCES  AUTHORITY  BALANCE  INSUFFICIENT  TO  ISSUE  PWA 
MA PY FS  _ PWC  

BALANCE  S_, , , _• UPDATE  » ' • — ~ 

D 1 1 0 ALLOTMENT  RECORD  NOT  FOUND 

MA PY FS  _ PWC 

D112  ALLOTMENT  ISSUES  INSUFFICIENT 

MA  __  PY  __  FS  _ PWC 

ISSUES  , • UPDATE  $_, , , • — " 

D113  ALLOTMENT  BALANCE  INSUFFICIENT  TO  ISSUE  PWA 
MA PY FS  _ PWC  

BALANCE  , , • UPDATE  r r • — * 

D"!  40  PWA  RECORD  NOT  FOUND 

MA PY FS  _ RO PWC  

OBJECT  CLASS  CARRIER  ID  SUB  ID  — 

D 1 41  PWA  BALANCE  INSUFFICIENT  TO  DECREASE  RECEIPTS 

MA PY FS RO PWC  

OBJECT  CLASS  CARRIER  ID  SUB  ID  — 

BALANCE  , , • UPDATE  $_, , , • — * 

D1 50  CARRIER  RECORD  NOT  FOUND 

MA PY FS  _ CARRIER  ID  

D151  CARRIER  BALANCE  INSUFFICIENT  TO  DECREASE  RECEIPTS 

MA PY FS  _ CARRIER  ID  

BALANCE  , r • UPDATE  , , • — " 

0160  SUB  PERFORMANCE  RECORD  NOT  FOUND 

MA  _ PY FS  _ RO PWC  SUB  ID 

D161  SUB  PERFORMANCE  AMOUNT  INSUFFICIENT 

MA  _ PY FS  _ RO PWC  SUB  ID 

AMOUNT  , , • UPDATE  , , • — ~ 

Figure  2.4-8.  - Primary  Work  Authorization 
processing  error  messages. 


2.4-19 


-20 


Messages  A 
0 
0 

Transaction  0 

Conventional  PWA  X 

Reservation  PWA  X 

Sub-RA  PWA  X 


BBBB  BBBBBBB 

00111111111 
1 1 0 0 1 1 1 1 2 2 2 

0 1 0 1 0 1 5 7 0 1 2 

XXXXXXX  XX 

X X X X X X X X X 

X X X X X XXX 


bbbbbbbbbbbbb 

1111111111111 

3335566677777 

0180101201456 

XX  X X X X X 

XX  XX  XXX  XX 

XX  xxxxxx 


Transaction 

Conventional  PWA 

Reservation  PWA 

Sub-RA  PWA 
to 

■c 


Messages  B B B B B B 

1112  2 2 
9 9 9 0 0 1 

0 12  0 10 

X X X X X 

xxxxxx 

XXX 


bbbbbbbc  cd 

266699955  1 

1 0 0 0 1 1 1 0 0 0 

10  12012010 

XXX  XXXX  X 

XX  X XXXXX  X 

XXXXXXX  X 


ddddddddddd 

11111111111 

00111445566 

23023010101 

XXXXXXX 

XXX  xxxxxx 

XXXXXXX  XX 


Figure  2.4-9 


- Primary  Work  authorization  Messages  by  transaction 


I n^uirx_de script ion 


Type 


Timing 


Resources  and  Program 
Management  Conventional 
PWA  Fund  Control  status 


Conventional  PWA  Fund 
Control  status 


Resources  and  Program 
Management  Reservation 
Fund  Control  status 


Reservation  PWA  Fund 
Control  status 


Carrier  Fund  Control 
status 


Resources  and  Program 
Management  Sub-RA  PWA 
Control  status 


Item 


Item 


PWA 


Item 


Item 


Item 

Fund 


Tn^ut  data  elements 


Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class  (funding) 
Responsible  Organization 


Immediate 


Method  of  Authority 
Program  Year 
Fund  Source 
Primary  Work.  Code 
(five  digits) 
Responsible  Organization 


Immediate 


R espouse  data  elements 


Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class 

Responsible  Organization 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 

Method  of  Authority 
Program  Year 

Fund  Source  . ..  . 

Primary  Work  code  (five-digits) 
Responsible  Organization 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 


Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class  (funding) 
Carrier  Identifier 
Responsible  organization 


Immediate 


Method  of  Authority 
Program  Year 
Fund  Source 
Primary  Work  Code 
(five  digits) 

Carrier  Identifier 
Responsible  Organization 


Immediate 


Responsible  organization  Immediate 
Carrier  Identifier 


Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class 
Carrier  Identifier 
Responsible  organization 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 

Method  of  Authority 
Program  Year 

Fund  Source  ..  . 

Primary  Work  Code  (fxve  digits) 
Carrier  Identifier 
Responsible  Organization 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 

Carrier  Identifier 
Carrier  receipts 
Carrier  issues 
Carrier  balance 


Program  Year 
Fund  Source 

Responsible  Organization 

Subauthorization 

Identifier 


Immediate 


Method  of  Authority 
Program  Year 
Fund  Source 

Responsible  Organization^ 
Subauthorization  Identifier 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-F.A  PWA  balance 


Figure  2.4-10.  - Primary 


Work  Authorization  inquiry  requirements. 


Inquiry  description 


T^£G 


Timing 


Sub-RA  PWA  Fund  Control 
status 


Resources  and  Program 
Management  PWA  Fund 
Control  summary  by  Object 
Class 


PWA  Fund  Control  summary 
by  a five-digit  Primary 
Work  Code 


Construction  of  Facilities 
PWA  Fund  Control  summary 
by  a four-digit  Primary 
Work  Cede 


I nput  data  elements 


Item  Program  Year  Immediate 

Fund  Source 
Primary  Work  Code 
(five  digits) 

Responsible  organization 

Subauthorization 

Identifier 


Summary  Method  of  Authority  Immediate 

Program  Year 
Fund  Source 
object  Class  (funding) 


Summary  Method  of  Authority  Immediate 

Program  Year 
Fund  Source 
Primary  Work  Code 
(five  digits) 


Summary  Method  of  Authority  Immediate 

Program  Year 
Fund  Source 
Primary  Work  Code 
(four  digits) 


S£§£onse_data  elements 


Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (five  digits) 
Responsible  Organization 
Subauthorization  Identifier 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  P~a  balance 

Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class  (funding) 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (five  digits) 
Conditional  PWA  receipts 
Conditional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (four  digits) 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 


Figure  2.4-10.  - Primary  Work  Authorization  inquiry  requirements  (continued) 


InquirY-description 


Type 


Input  data  elements 


Timing 


PEA  Primary  Work  Code 
total  at  a three-digit 
Primary  Work  Code  level 
(Fund  Source  4,  9,  and 
11  only) 


PW A Fund  Control  summary 
by  Fund  Source 


PWA  Fund  Control  summary 
by  appropriation 


Response  data  elements 


Summary  Hethod  of  Authority 

Program  Year 
Fund  Source 
Primary  Work  Code 
(three  digits) 


Summary  Hethod  of  Authority 

Program  Year 
Fund  Source 


Summary  Method  of  Authority 

Program  Year 
Appropriation  type 


Sub-EA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Immediate  Method  of  Authority 

Program  Year 
Fund  Source 

Primary  Work  Code  (three  digits) 

Conventional  PWA  receipts 

Conventional  PWA  issues 

Conventional  PWA  balance 

Reservation  PWA  receipts 

Reservation  PWA  issues 

Reservation  PWA  balance 

Total  PWA  receipts 

Total  PWA  Issues 

Total  PWA  balance 

Sub-RA  PWA  receipts 

Sub-RA  PWA  Issues 

Sub-RA  PWA  balance 

Total  receipts 

Total  issues 

Total  balance 

Immediate  Method  of  Authority 

Program  Year 
Fund  Source 

Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Immediate  Method  of  Authority 

Program  Year 
Appropriation  symbol 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 


Figure  2.4-10.  - Primary  Work  Authorization  inquiry  requirements  (continued) 


Inquiry  description 


ta^eleaen ts 


Timing 


Response  data  elements 


PWR  Fund  Control  summary  Summary  Method  of  Authority  Immediate 

by  Program  Year  • Program  Year 


PtfA  Fund  Control  summary  Summary  Method  of  Authority  Immediate 

by  Method  of  Authority 


PWA  grand  total 


Summary  None  required 


Immediate 


Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Method  of  Authority 
Program  Year 

Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-KA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Method  of  Authority 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 


Figure  2.4-10.  - Primary  Work  Authorization  inquiry  requirements  (continued). 


Inquiry  description 


tie® 


Timing 


PH A Responsible  Organiza- 
tion Fund  Control  summary 
by  a three-digit  Primary 
work  Code 


pH A Responsible  Organiza- 
tion Fund  Control  summary 
by  a four-digit  Primary  Hork 
Code 


PH A Responsible  organiza- 


Summary  Responsible  Organization  Immediate 

Method  of  Authority 
Program  Year 
Fund  Source 
Primary  Work  Code 
(three  digits) 


Summary 


Responsible  organization  Immediate 
Method  of  Authority 
Program  Year 
Fund  Source 
Primary  Work  Code 
(four  digits) 


data  elements 


Total  PH A balance 
Sub-RA  PH A receipts 
Sub-RA  PHA  issues 
Sub-BA  PHA  balance 
Total  receipts 
Total  issues 
Total  balance 
Carrier  receipts 
Carrier  issues 
Carrier  balance 

Responsible  organization 
Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Hork  Code  (three  digits) 

Conventional  PHA  receipts 

Conventional  PHA  issues 

Conventional  PHA  balance 

Reservation  PHA  receipts 

Reservation  PHA  issues 

Reservation  PHA  balance 

Total  PHA  receipts 

Total  PHA  issues 

Total  PHA  balance 

Sub-RA  PHA  receipts 

Sub-RA  PHA  issues 

Sub-RA  PHA  balance 

Total  receipts 

Total  issues 

Total  balance 

Responsible  Organization 
Method  of  Authority 
Program  Year 
Fund  Source 

primary  Hork  Code  (four  digits) 

Conventional  PHA  receipts 

Conventional  PHA  issues 

Conventional  PHA  balance 

Reservation  PHA  receipts 

Reservation  PHA  issues 

Reservation  PHA  balance 

Total  PHA  receipts 

Total  PHA  issues 

Total  PHA  balance 

Sub-RA  PHA  receipts 

Sub-FA  PHA  issues 

Sub-RA  PHA  balance 

Total  receipts 

Total  issues 

Total  balance 


Summary  Responsible  Organisation  Immediate  Responsible  Organization 


Figure  2.4-10.  - Primary 


Hork  Authorization  inquiry  requirements  (continued) 


Inquiry  description 


Timing 


E§s£gnse_data_elements 


tion  Fund  Control  summary 
by  Fund  Source 


PWA  Responsible  Organiza- 
tion  Fund  Control  summary 
by  Program  Year 


fO 


to 

o> 


PWA  Responsible  Organiza- 
tion Fund  Control  summary 
by  Method  of  Authority 


Method  of  Authority 
Program  Year 
Fund  Source 


Summary  Responsible  Organization 

Method  of  Authority 
Program  Year 


Summary  Responsible  organization 

Method  of  Authority 


Method  of  Authority 
Program  Year 
Fund  Source 

Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PSA  receipts 
Total  PWA  issues 
Total.  PWA  balance 
Sub‘-iU  PWA  receipts 
Sivn-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Immediate  Responsible  Organization 

Method  of  Authority 
Program  Year 

Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Immediate  Responsible  Organization 

Method  of  Authority 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-BA  PWA  balance  ' 

Total  receipts 
Total  issues 


. - Primary  Work.  Authorization  inquiry  requirements  (continued). 


Figure  2.4-10 


LZ- 


illiulry_descriptiqn 


input_data_elements 


Timing 


Resg°nse  data  elements 


PHA  Responsible  Organiza- 
tion Fund  Control  summary 


PHA  Fund  Control  list  of 
Carriers 


fO 

■SZ 

resources  and  Program 
Management  PHA  Fund 
Control  list 


PW  A Fund  Control  list 


Summary 


List 


List 


List 


Responsible  Organization  Immediate 


None  required 


Immediate 


Method  of  Authority  Immediate 

Program  Year 

Fund  Source 

Object  Class  (funding) 


Method  of  Authority  Immediate 

Program  Year 
Fund  Source 


Total  balance 

Responsible  Organization 
Conventional  PHA  receipts 
Conventional  PHA  issues 
Conventional  PHA  balance 
Reservation  PHA  receipts 
Reservation  PHA  issues 
Reservation  PHA  balance 
Total  PHA  receipts 
Total  PHA  issues 
Total  PHA  balance 
Sub-RA  PHA  receipts 
Sub-RA  PHA  issues 
Sub-RA  PHA  balance 
Total  receipts 
Total  issues 
Total  balance 

Responsible  Organization 
Carrier  Identifier 
Carrier  receipts 
Carrier  issues 
Carrier  balance 
Total  Carrier  receipts 
Total  Carrier  issues 
Total  Carrier  balance 

Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class  (funding) 
Responsible  organization 
Carrier  Identifier 
Subauthorization  Identifier 
Conventional  PHA  receipts 
Conventional  PHA  issues 
Conventional  PHA  balance 
Reservation  PHA  receipts 
Reservation  PHA  issues 
Reservation  PHA  balance 
Total  PHA  receipts 
Total  PHA  issues 
Total  PHA  balance 
Sub-RA  PHA  receipts 
Sub-RA  PHA  issues 
Sub-RA  PHA  balance 
Total  receipts 
Total  issues 
Total  balance 

Method  of  Authority 
Program  Year 
Fund  Source 


Figure  2.4-10.  - Primary  Hork  Authorization  inquiry  requirements  (continued) 


Inquiry . description 


i!I22t_data_elements 


Timing 


se_d  a ta  _elenien  ts 


Resources  and  Program 
Management  PWA  Responsible 
Organization  Fund  Control 


list 


List 


PWA  Responsible  Organiza-  List 
tion  Fund  Control  list 


Primary  Work  Code 
(five  digits) 


Responsible  Organization  Immediate 
Method  of  Authority 
program  Year 
Fund  Source 


Responsible  Organization  Immediate 
Method  of  Authority 
Program  Year 
Fund  Source 


primary  Work  Code  (five  digits) 

Responsible  Organization 

Carrier  Identifier 

Subauthorization  Identifier 

Conventional  PWA  receipts 

Conventional  PWA  issues 

Conventional  PWA  balance 

Reservation  PWA  receipts 

Reservation  PWA  issues 

Reservation  PWA  balance 

Total  PWA  receipts 

Total  PWA  issues 

Total  PWA  balance 

Sub-RA  PWA  receipts 

Sub-RA  PWA  issues 

Sub-RA  PWA  balance 

Total  receipts 

Total  issues 

Total  balance 

Responsible  Organization 
Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class 
Carrier  Identifier 
Subauthorization 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Responsible  Organization 
Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (five  digits) 
Carrier  Identifier 
Subauthorization  Identifier 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 


Figure  2,4-10.  - Primary  Work  Authorization  inguiry  requirements  (continued). 


ORIGINAL  PAGE  IS 
OF  POOR  QUALITY! 


Inquiry  description  Type  Input  data  elements 


Resources  and  Program  List 

Management  Resources 
Authority/PWA  Fund  Control 
list 


Method  of  Authority 
Program  Year 
Fund  Source 
Dollar  limit 


f 


to 

-C 

I 

to 

VO 


Research  and  Development  List  Method  of  Authority 

Resources  Authority/PWA  Program  Year 

Fund  Control  list  Fund  Source 

Primary  Work  Code 
(three  digits) 
Dollar  limit 


Timing 


\ ■ f 


Response  data  elements 


Reservation  PWA  issues 
Reservation  PWA  balance 
Total  PWA  receipts 
Total  PWA  issues 
Total  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 
Total  receipts 
Total  issues 
Total  balance 

Same  day  Method  of  Authority 

Program  Year 
Fund  Source 
Dollar  limit 

Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 
Object  Class  (funding) 
Responsible  Organization 
Carrier  Identifier 
Sub  Authorization  Identifier 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Sub-RA  PWA  receipts 
Sub-RA  PWA  issues 
Sub-RA  PWA  balance 

Same  day  Method  of  Authority 

Program  Year 
Fund  Source 

Primary  Work  Code  (three  digits) 
Dollar  limit 

Resources  Authority  receipts 
Resources  Authority  issues 
Resources  Authority  balance 
primary  Work  Code  (five  digits) 
Responsible  Organization 
Carrier  Identifier 
Subauthorization  Identifier 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 
Sub-RA  PWA  receipts  * 

Sub-RA  PWA  issues 
Sub-RA  PWA  balance 


inquiry  requirements  (continued) . 


Inquiry  description 

Input  data  elements 

Timihq 

Response  data  elements 

Construction  of  Facilities 
Resources  Authority/PW A 
Fund  Control  list 

List 

Method  of  Authority 
Program  Year 
Fund  Source 
Primary  Work  Code 
(foUr  digits) 
Dollar  limit 

Same  day 

Method  of  Authority 
Program  Year 
FUnd  Source 

Primary  Work  Code  (four  digits) 
Dollar  limit 

Resources  Authority  receipts 

Resources  authority  issues 
Resources  Authority  balance 
Primary  Work  Code  (five  digits) 
Responsible  organization 
Carrier  Identifier 
Subauthorization  Identifier 
Conventional  PWA  receipts 
Conventional  PHA  issues 
Conventional  PWA  balance 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 


Figure  2.4-10.  - Primary  Work  Authorization  inquiry  requirements  (concluded). 


2.5  REIMBURSABLE  ORDER  ACCEPTANCE  PROCESS 


Reimbursable  Order  Acceptance  is  the  official  agreement 
between  JSC  and  a non-NASA  source  for  reimbursable  work  to 
be  performed  by  JSC.  The  agreement  establishes  the  work  to 
be  performed  and  the  dollar  amount  of  the  reimbursement  to 
be  received  for  the  work  performed.  All  reimbursable  work 
at  JSC  is  funded  through  Reimbursable  RA  and  Reimbursable 
Allotment  issued  to  JSC  based  on  the  projected  amount  of 
work  to  be  performed  for  these  non-NASA  sources.  Each 
Reimbursable  Order  Acceptance  reserves  Reimbursable  RA  and 
Reimbursable  Allotment  for  the  dollar  amount  of  each 
reimbursable  order  accepted. 

2.5.1  Update  Requirements 

The  Central  Resources  Control  Section  receives  the 
Reimbursable  Order  Acceptance  document  where  the  required 
information  is  to  be  entered  into  the  online  system.  JSC 
work  on  each  reimbursable  order  is  tracked  through  one  or 
more  unique  nine-digit  PWC's  assigned  to  an  order.  The 
number  of  PWC's  required  depends  on  the  characteristics  of 
the  work  to  be  performed  with  some  orders  having  multiple 
FS's  applicable  and  multiple  PWC's  required  to  best  describe 
the  nature  of  the  work  performed.  A Reimbursable  Order 
Number  is  assigned  to  each  order  to  permit  multiple  PWC 
assignments.  The  Central  Resources  Control  Section  must 
enter  each  unique  nine-digit  PWC  applicable  into  the  PWC 
edit  validation  table  (see  section  2.16)  and  must  assign  the 
Reimbursable  Order  Number  prior  to  the  input  of  any 
reimbursable  order  transaction. 


Three  transactions  are  defined  for  processing 
reimbursable  order  information.  The  Reimbursable  Order 
Accepted  transaction  permits  input  of  the  Reimbursable  Order 
Number  and  the  dollar  amount  of  the  order.  The  Reimbursable 
Order  Assigned  transaction  permits  reservation  of 
Allotment,  assignment  of  FS,  and  input  of  the  unique  nine- 
digit PWC  given  for  that  FS.  The  Reimbursable  Order 
Transferred  transaction  permits  assignment  of  funds  to 
additional  unique  nine-digit  PWC's  within  one  FS.  Input, 
processing,  and  output  requirements  will  be  discussed  by 
transaction. 

2.5. 1.1  Reimbursable  Order  Accepted.  All  Reimbursable 
Order  Acceptance  (ROA)  documents  are  to  be  recorded  using 
the  Reimbursable  Order  Accepted  transaction.  The 
information  recorded  by  the  transaction  will  update  the 
Reimbursable  Order  Control  account.  This  account  provides 
the  necessary  control  to  assure  that  the  order  total  will 
not  be  exceeded  regardless  of  the  number  of  PWC  and  FS 
assignments  or  transfers. 

Input  - Figure  2.5-1  contains  a list  of  the  elements 
that  must  be  input  for  the  Reimbursable  Order  Accepted 
transaction. 

Figure  2.5-2  defines  the  reimbursable  order  template. 
The  template  illustrated  will  be  used  for  all  Reimbursable 
Order  Accepted,  Assigned,  and  Transferred  transactions. 


Data 

Element 

Error 

Error 

element 

required 

Source 

t,2£e_ 

Input/Edit  requirements 

code 

•As  of* 

Optional 

User 

Fatal 

Date  providing  for  the  backdating  of  transactions. 

B 1 00 

Date 

supplied 

Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

B101 

Reimbursable 

Yes 

User 

Fatal 

Identification  number  of  the  reimbursable  order. 

B250 

Order  Number 

supplied 

Input  for  all  Reimbursable  Order  Accepted  trans- 

B251 

actions.  Must  be  numeric  and  greater  than  0. 

B252 

Amendment 

Yes 

R3A  or 

Fatal 

Identification  number  of  the  reimbursable  order 

B920 

Number 

user 

source  document.  Input  for  all  Reimbursable  Order 

B921 

supplied 

Accepted  transactions.  Must  be  numeric  and  not 
less  than  0. 

B922 

Dollar 

Yes 

ROA 

Fatal 

Input  for  all  Reimbursable  Order  Accepted  trans- 

B600 

Amount 

actions.  Must  be  numeric  and  not  equal  to  0. 

B601 

B602 

Hethod  of 

Yes 

ROA 

Fatal 

Input  for  all  Reimbursable  Order  Accepted  trans- 

B  1 1 0 

Authority 

actions.  Must  be  numeric  and  in  the  range  80 

Bill 

through  99,  excluding  97. 

B 1 1 4 

Program  Year 

Yes 

ROA 

Fatal 

Input  for  all  Reimbursable  Order  Accepted  trans- 

B1 20 

actions.  Must  be  a valid  PY. 

B 1 21 

Fund  Source 

No 

None 

Fatal 

Must  not  be  input  for  any  Reimbursable  Order 
Accepted  transaction. 

B 1 41 

Primary  Work 

No 

None 

Fatal 

Must  not  be  input  for  any  Reimbursable  Order 

B 1 75 

Code 

Accepted  transaction. 

Type  of 

Yes 

User 

Fatal 

Transaction  indicator.  Input  as  a Reimbursable 

B0  1 0 

transaction 

supplied 

Order  Accepted  transaction. 

B011 

Correction 

Optional 

User 

None 

Transaction  modifier  indicating  that  the  trans- 

None 

supplied 

action  is  a correction.  Input  only  when  the  trans- 
action is  a correction. 

Figure  2.5-1.  - Reimbursable  Order  Accepted  input  and  edit  requirements. 


****IFMS  SEPTEMBER  30,  1974  AS  OF / /„ 

♦♦♦♦TEMPLATE  NO.  G2-  REIMBURSABLE  ORDER  TEMPLATE 

R3SIMB  ORDER  NO.  AMENDMENT  NO.  AMOUNT  $ 

MA  __  PY FS PWC  _ 

TYPE  OF  TRANSACTION: 

REIMB  ORDER  ACCEPTED 
REIMB  ORDER  ASSIGNED 
REIMB  ORDER  TRANSFERRED  _ PtfC 
CORRECTION 


Figure  2.5-2.  - Reimbursable  Order  template 


2.  5-4 


Processing.  - The  Reimbursable  Order  Accepted 
transaction  must  maintain  detailed  history  information  for 
each  basic  reimbursable  order  and  associated  amendments  and 
must  maintain  the  cumulative  total  order  value  of  the  order. 
The  cumulative  order  value  and  the  detailed  history 
information  are  maintained  as  the  control  entry  and  the 
detailed  history  information  entries  respectively  in 
Reimbursable  Order  Control  account  entries  identified  by  the 
Reimbursable  Order  Number. 

If  a basic  reimbursable  order  is  being  accepted 
(amendment  number  is  equal  to  0) , the  order  control  entry 
must  be  generated  with  the  following  data  elements: 

• Reimbursable  Order  Number 

'•  Dollar  Amount  (acceptance) 

Only  positive  dollar  amounts  are  permitted  for  the  basic 
ROA. 

The  acceptance  of  an  amendment  to  an  existing 
reimbursable  order  updates  the  control  entry  acceptance 
amount  identified  by  the  basic  order  number  input.  A 
positive  dollar  amount  increases  the  control  entry 
acceptance  amount  while  a negative  dollar  amount  decreases 
the  amount.  However,  any  update  must  not  result  in  a 
negative  balance  in  the  control  entry  of  the  order. 

A detailed  history  information  entry  for  every  ROA 
recorded  (both  basic  and  amendments)  must  be  generated  using 
the  following  elements. 
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• Reimbursable  Order  Number 

• Reimbursable  Order  Amendment  Number 

• Method  of  Authority 

• Program  Year 

• Dollar  Amount  (of  the  ROA) 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  and  correction  transactions  will  be  identified  in 
the  transaction  history. 

Qutput  ~ Section  2.5.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Reimbursable  Order  Accepted  transaction. 

2. 5. 1.2  ReimbursableinOrder  Assigned.  The  assignment  of 
an  allotment  to  each  ROA  processed  and  the  unique  nine-digit 
PWC  and  FS  assignments  are  to  be  input  as  a Reimbursable 
Order  Assigned  transaction.  Assignment  of  an  allotment  to  a 
reimbursable  order  transfers  the  allotment  from  the 
Reimbursable  Allotment  Suspense  subaccount  to  the 
Reimbursable  Allotment  subaccount.  This  transaction  follows 
the  recording  of  the  basic  order  dollars  or  amendment 
dollars  and  the  detailed  history  information  as  specified  by 
the  Reimbursable  Order  Accepted  transaction  described  in  the 
prior  section. 

Input  - Figure  2. 5-3  contains  a list  of  the  elements 
that  must  be  input  for  the  Reimbursable  Order  Assigned 
transaction. 


2. 5-6 


5-7 


Data 

element 

Element 

required 

Source 

Error 

S.IEe_ 

Input/Fdit  requirements 

Error 

code 

•As  of1 
Date 

Optional 

User 

supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

E100 

Bl  0 1 

Reimbursable 
Order  Humber 

Yes 

User 

supplied 

Fatal 

Identification  number  of  the  reimbursable  order. 
Input  for  all  Reimbursable  Order  Assigned  trans- 
actions. Must  be  numeric  and  greater  than  0. 
Also  validated  with  PWC. 

B250 

B251 

B252 

C504 

Amendment 

Number 

Yes 

ROA  or 
user 

supplied 

Fatal 

Identification  number  of  the  reimbursable  order 
source  document.  Input  for  all  Reimbursable 
Order  Assigned  transactions.  Must  be  numeric 
and  not  less  than  0. 

B920 

B921 

B922 

Doll  a r 
Amount 

Yes 

RDA 

Fatal 

Input  for  all  Reimbursable  order  Assigned  trans- 
actions. Must  be  numeric  and  not  egual  to  0. 

B600 

B601 

B602 

Method  of 
Authority 

Yes 

ROA 

Fatal 

Input  for  all  Reimbursable  order  Assigned  trans- 
actions. Must  be  a valid  MA  but  not  97. 

Bl  10 
Bill 
B 1 1 4 

program  Year 

Yes 

RDA 

Fatal 

Input  for  all  Reimbursable  Order  Assigned  trans- 
actions. Must  be  a valid  PY.  Also  validated 
with  FS. 

B 1 20 
B 1 2 1 
C500 

Fund  Source 

Yes 

ROA 

Fatal 

Input  for  all  Reimbursable  Order  Assigned  trans- 
actions. Must  be  in  the  range  1 through  9 or  11. 
Also  validated  with  PY. 

B 130 
C500 
C502 

primary  Work 
Code 

Yes 

ROA 

Fatal 

Input  for  all  Reimbursable  Order  Assigned  trans- 
actions. Must  be  nine  digits.  Also  validated 
with  Reimbursable  Order  Number. 

B 1 7 0 
B 1 7 1 
Bl  74 

Type  of 
transaction 

Yes 

User 

supplied 

Fatal 

Transaction  indicator.  Input  as  a Reimbursable 
Order  Assigned  transaction. 

B0 1 0 
B0 1 1 

Correction 

Conditional 

User 

supplied 

None 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction. 

None 

Figure  2.5-3.  - Reimbursable  Order  Assigned  input  and  edit  reguirements. 


Figure  2.5.2  defines  the  reimbursable  order  template. 
The  template  illustrated  will  be  used  for  all  Reimbursable 
Order  Accepted,  Assigned,  and  Transferred  transactions. 

££2£§§§iS3  ~ Because  the  cumulative  order  value  and  the 
Reimbursable  Allotment  are  the  limiting  controls  for  the 
Reimbursable  Order  Assigned  transaction  updates,  the 
applicable  Reimbursable  Order  Control  account  control  entry 
(identified  by  the  Reimbursable  Order  Number) , . and  the 
Reimbursable  Allotment  Suspense  subaccount  entry  (identified 
by  MA,  PY,  and  appropriation  level  FS)  must  be  referenced. 
The  FS  input  to  the  transaction  must  be  converted  to  the 
applicable  appropriation  level  FS. 

A positive  dollar  amount  requires  both  the  Reimbursable 
Order  Control  account  control  entry  and  the  Reimbursable 
Allotment  Suspense  subaccount  entry  to  have  sufficient 
balance  to  complete  the  action  required  by  the  Reimbursable 
Order  Assigned  transaction.  The  posting  must  result  in  an 
increase  to  the  applicable  Reimbursable  Order  Control 
account  control  entry  assignment  amount,  a decrease  to  the 
Reimbursable  Allotment  Suspense  subaccount  entry  receipts, 
and  an  increase  to  the  Reimbursable  Allotment  subaccount 
entry  receipts.  The  Reimbursable  Allotment  subaccount  entry 
applicable  is  identified  by  MA,  PY,  funding  level  FS,  and  a 
nine-digit  PWC.  If  the  Reimbursable  Allotment  subaccount 
entry  does  not  already  exist  in  the  data  base,  it  must  be 
generated  with  the  following  data  elements: 

• Reimbursable  Order  Number 

• Reimbursable  Order  Amendment  Number 

• Method  of  Authority 
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• Program  Year 

• Fund  Source  (funding  level) 

• Primary  Work  Code 

• Dollar  Amount  (receipts) 

A negative  dollar  amount  in  this  transaction  must 
result  in  the  posting  of  a decrease  to  the  Reimbursable 
Order  Control  account  control  entry  assignment  amount,  a 
decrease  to  the  Reimbursable  Allotment  subaccount  entry 
receipts,  and  an  increase  to  the  Reimbursable  Allotment 
Suspense  subaccount  entry  receipts.  A negative  balance  must 
not  occur  in  any  of  the  defined  account/subaccount  entries. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  and  correction  transactions  will  be  identified  in 
the  transaction  history. 

~ Section  2.5.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Reimbursable  Order  Assigned  transaction. 

2.5. 1.3  Reimbursable Order Transferred.  The 

Reimbursable  Order  Tr?insferred  transaction  reassigns 
Reimbursable  Allotment  from  one  nine-digit  PWC  to  another 
nine-digit  PWC  within  the  same  FS.  The  transfer  transaction 
provides  the  ability  to  assign  multiple  nine-digit  PWCs  for 
each  reimbursable  order  requiring  a more  detailed  task 
assignment  breakout. 


Error 

Input/Edit_reguireaeDts 

Date  providing  for  the  backdating  of  trans-  B100 

actions-  Input  only  when  a transaction  date  BIOT 

other  than  the  system  date  is  desired.  When 
input,  must  be  numeric  and  conform  to  all  normal 
date  edits. 


Identification  number  of  the  reimbursable  order.  B250 

Input  for  all  Reimbursable  order  Transferred  B2bi 

transactions.  Must  be  numeric  and  greater  than  0.  B252 

Also  validated  with  PWC.  C504 

Identification  number  of  the  reimbursable  order  Bqoi 

memorandum  directing  the  transfer.  Input  for  all  B92T 

Reimbursable  Order  Transferred  transactions.  Bust  B922 

be  numeric  and  not  less  than  500. 

Input  for  all  Reimbursable  Order  Transferred  B600 

transactions.  Must  be  numeric  and  not  equal  to  B601 

0.  B602 

Input  for  all  Reimbursable  Order  Transferred  B110 

transactions.  Must  be  a valid  MA  but  not  97. 

Input  for  all  Reimbursable  order  Transferred  B120 

transactions.  Must  be  a valid  PY.  Also  B121 

validated  with  FS.  CbUU 

Input  for  all  Reimbursable  Order  Transferred  B130 

transactions.  Must  be  a funding  FS.  Also  C500 

validated  with  PY.  ..  G50^ 

PWC  for  transferor  Reimbursable  Allotment  sub- 
account.  Must  be  nine  digits  and  must  not  be  B171 

the  same  as  the  PWC  for  transferee  Reimburs-  Bi /4 

able  Allotment  subaccount.  817 ' 

Transaction  indicator.  Input  as  Reimbursable  B010 

Order  Transferred  transaction.  BOH 

PWC  for  transferee  Reimbursable  Allotment  sub-  B1Z? 

account.  Must  be  nine  digits  and  must  not  be  the  B171 

same  as  the  PWC  for  transferor  Reimbursable  B174 

Allotment  subaccount.  B177 

Transaction  modifier  indicating  that  the  trans-  None 

. action  is, a correction.  Input  only  when  the 
transaction  is  a correction.  • 


Order  Transferred  input  and  edit  requirements. 


4 contains  a list  of  the  elements 
that  must  be  input  for  the  Reimbursable  Order  Transferred 
transaction. 

Figure  2.5-2  defines  the  reimbursable  order  template 
used  for  all  Reimbursable  Order  Acceptance,  Reimbursable 
Order  Assignment,  and  Reimbursable  Order  Transferred 
transactions. 

EEocessing  - The  Reimbursable  Order  Transferred 
transaction  must  reference  two  entries  in  the  Reimbursable 
Allotment  subaccount  to  perform  the  requested  transfer.  The 
first  entry  referenced  (transferor)  is  the  limiting  control 
for  the  transaction  and  must  already  exist  in  the 
subaccount.  It  is  identified  by  MA,  PY,  funding  level  FS, 
and  a nine-digit  PWC(1).  The  second  entry  referenced 
(transferee)  receives  the  funds  assigned  and  is  identified 
by  MA,  PY,  funding  level  FS,  and  a nine-digit  PWC  (2)  . 

A positive  dollar  amount  requires  the  transferor  to 
have  sufficient  balance  to  complete  the  transfer.  The 
posting  must  result  in  a decrease  to  the  transferor  receipts 
and  a corresponding  increase  to  the  transferee  receipts. 

A negative  dollar  amount  in  this  transaction  must 
result  in  the  posting  of  an  increase  to  the  transferor 
receipts  and  a corresponding  decrease  to  the  transferee 
receipts.  A negative  balance  must  not  occur  in  either 
entry . 

[ V 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 


Input  - Figure  2.5- 


2.5-1 1 


Initial,  update,  and  correction  transactions  will  be 
identified  in  the  transaction  history. 

QfitEUi  • Section  2.5.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Reimbursable  Order  Transferred 
transaction.  • 


2.5.2  Output  Message  Requirements 

Figures  2.5-5  through  2.5-8  contain  a list  of  output 
message  requirements.  Figure  2.5-9  contains  a correlation 
of  output  messages  by  transaction. 

2.5.3  Inquiry  Requirements 

Figure  2.5-10  contains  a list  of  inquiry  input  data' 
elements  and  response  data  elements  required  for 
reimbursable  order  processing. 

2.5.4  Report  Requirements 

Section  2.19.1  lists  the  Fund  Control  report 
requirements.  The  Reimbursable  Order  Fund  Control  Status 
report  reflects  Reimbursable  Order  Acceptance  account 
activity. 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  Reimbursable  Order  Section  report 
described  in  section  2.19.7. 


2.5-12 


£2&e 


fle§s§ae 


^1  .S' 

****  REIMBURSABLE  ORDER  ACCEPTED 

****  REIMBURSABLE  ORDER  ASSIGNED 

****  REIMBURSABLE  ORDER  TRANSFERRED 

B010  TYPE  OF  TRANSACTION  NOT  SPECIFIED 

B0 1 1 MULTIPLE  TYPES  OF  TRANSACTION  SPECIFIED 

Figure  2.5-5.  - Reimbursable  Order  Acceptance 
transaction-begun  messages. 

Code  Message 

A000  PROCESSING  COMPLETE 

\ Figure  2.5-6.  - Reimbursable  Order  Acceptance 

transaction -complete  messages. 


Message 


Code 

B 1 00  'AS  OF'  DATE  INVALID 

B 1 01  'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE  __/ / 

B110  MA  NOT  ENTERED 
Bill  MA  INVALID 

B 1 1 4 MA  MUST  BE  80  TO  99  BUT  NOT  97 

B1 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

B 1 30  FS  NOT  ENTERED 

B 1 41  FS  MUST  BE  BLANK 

B 1 70  PWC  NOT  ENTERED 

B 171  PWC  INVALID 

B 1 7 4 PWC  MUST  BE  9 DIGITS 

B 1 75  PWC  MUST  BE  BLANK 

B 1 77  DUPLICATE  9 DIGIT  PWC'S  ENTERED 

B250  REIMBURSABLE  ORDER  NUMBER  NOT  ENTERED 

B251  REIMBURSABLE  ORDER  NUMBER  INVALID 

B252  REIMBURSABLE  ORDER  NUMBER  MUST  BE  GREATER  THAN  ZERO 

E600  $ AMOUNT  NOT  ENTERED 

B601  $ AMOUNT  INVALID 

B602  $ AMOUNT  MUST  NOT  BE  ZERO 

B920  AMENDMENT  NUMBER  NOT  ENTERED 

B921  AMENDMENT  NUMBER  INVALID 

B922  AMENDMENT  NUMBER  MUST  NOT  BE  LESS  THAN  ZERO 
C 500  PY,  FS  COMBINATION  INVALID 
C502  FS  IS  NOT  A FUNDING  FUND  SOURCE 

C504  PWC,  REIMBURSABLE  ORDER  NUMBER  COMBINATION  INVALID 


Figure  2.5-7.  - Reimbursable  Order  Acceptance 

data  element  edit  error  messages. 
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Code 


Message 


D 1 1 0 ALLOTMENT  RECORD  NOT  FOUND 

MA PY FS PWC  

Dill  ALLOTMENT  BALANCE  INSUFFICIENT  TO  DECREASE  RECEIPTS 
MA PY FS  PWC 

ISSUES  $_, , , . UPDATE  , , . - 

D120  REIMBURSABLE  SUSPENSE  RECORD  NOT  FOUND 

MA PY FS REIMB  ORDER  NO, 

D 1 2 1 REIMBURSABLE  SUSPENSE  BALANCE  INSUFFICIENT  TO  DECREASE  RECEIPTS 

MA PY FS REIMB  ORDER  NO. 

BALANCE  , f UPDATE  $_, , , . - 

D 170  REIMBURSABLE  ORDER  CONTROL  ACCOUNT  RECORD  NOT  FOUND 
MA PY REIMB  ORDER  NO. 

D 1 7 1 REIMBURSABLE  ORDER  CONTROL  BALANCE  INSUFFICIENT  INCREASE  ISSUES 

REIMB  ORDER  NO. 

AMOUNT  , , . UPDATE  , , . - 

D 1 72  REIMBURSABLE  ORDER  CONTROL  ISSUES  INSUFFICIENT  REIMB  ORDER  NO._ 

ISSUES  $_, , , . UPDATE  $_r f , . - 


Figure  2.5-8.  - Reimbursable  Order  Acceptance 
processing  error  messages. 


Transaction 


Messag 


Reimbursable  Order 
Accepted 

Reimbursable  Order 
Assigned 

Reimbursable  Order 
Transferred 


Message 

NJ 

* Transaction 


Reimbursable  Order 
Accepted 

Reimbursable  Order 
Assigned 

Reimbursable  Order 
Transferred 


ABBBBBBBB5 

0 0 0 1 1 1 1 111 
0110011122 

0010102401 


X X X X X X XXX 

XXXXXX  XXX 

XXXXXX  XXX 


bbbbbbbccc 
2666999555 
500022200  0 

2 0 1 2 0 1 2 0 1 2 


X X X X X X X 

xxxxxxxx  X 

XXXXXXXX  X 


Reimbursable  Order  Acceptance 


bbbbbbbbbb 

111111112  2 

2347777755 
2 0 1 0 1 4 5 7 0 1 


X XXX 
X XXX  XX 
X XXX  XXX 


CDDDDDDD 
5 1111111 
0 1 1 2 2 7 7 7 
4 0 1 0 1 0 1 2 


X 

XXXXXXXX 


XXX 


messages  by  transaction. 


Figure  2.5-9 


s ” , 

Hj  . -/ 


I[ia!iiEI_4§scrigtign  Type 


Reimbursable  Order  Control  Item 
account  status 


Reimbursable  Order  Control  Summary 
account  summary 


Reimbursable  Order  Control  Summary 

account  summary  by  Program 

Year 

Reimbursable  Oi.aer  Control  list 

account  list  by  Program 

Year 


Reimbursable  Allotment  Item 

Fund  Control  status 


Reimbursable  Allotment  List 

Fund  Control  list 


Foimbursable  Resources  Item 

and  program  Management 
Conventional  PKA  Fund 
Control  status 


Input  data  elements  Timing 


Reimbursable  Order  Immediate 

Number 

Amendment  Number 


Reimbursable  Order  Immediate 

Number 


Program  Year  Immediate 


Program  Year  Same  day 


Method  of  Authority  Immediate 
Program  Year 
Fund  Source  (funding 
level) 

Primary  Work  Code 
(nine  digits) 


Reimbursable  Order  Immediate 

Number 


Method  of  Authority  Immediate 

Program  Year 

Fund  Source 

Object  Class  (funding) 

Primary  Work  Code 
(nine  digits) 

Responsible  Organization 


Response  data  elements 


Reimbursable  Order  Huoher 
Method  of  Authority 
Program  Year 
Amendment  Number 

Reimbursable  Order  acceptance  amount 

Reimbursable  Order  Humber 
Method  of  Authority 
Reimbursable  Order  acceptance  amount 
Reimbursable  Order  assignment  amount 
Reimbursable  order  unassigned  balance 

Program  Year 

Reimbursable  Order  acceptance  amount 


Program  Year 
Method  of  Authority 
Reimbursable  Order  Number 
Reimbursable  Order  acceptance  amount 
Total  Method  of  Authority  acceptance 
amount 

Total  acceptance  amount 

Method  of  Authority 

Program  Year 

Fund  Source  (funding) 

Primary  Work  Code  (nine  digits) 
Reimbursable  Order  Number 
Reimbursable  Allotment  receipts 
Reimbursable  Allotment  issues 
Reimbursable  Allotment  balance 
Last  receipts  activity  information 
Last  issues  activity  information 

Reimbursable  Order  Number 
Method  of  Authority 

Reimbursable  Order  acceptance  amount 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Reimbursable  Allotment  receipts 
Reimbursable  Allotment  issues 
Reimbursable  Allotment  balance 
Total  receipts 
Total  issues 
Total  balance 

Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Conventional  PWA  receipts 
Conventional  PKA  issues 
Conventional  PWA  balance 


Figure  2.5-10.  - Reimbursable  Order  inquiry  requirements. 


01-' 


Inquiry  description 


Timing 


Response  data  elements 


Type 


t_da ta_elements 


to 

Ln 


Reimbursable  Conventional  Item 
P W A Fund  Control  status 


reimbursable  Resources  Item 

and  Program  Management 
Reservation  PWA  Fund 
Control  status 


reimbursable  Reservation  Item 

PWA  Fund  Control  status 


Method  of  Authority  Immediate 

Program  Year 
Fund  Source 
Primary  Work  Code 
(nine  digits) 

Responsible  Organization 


Method  of  Authority  Immediate 

Program  Year 

Fund  Source 

Object  Class  (funding) 

Primary  Work  Code 
Carrier  Identifier 
Responsible  Organization 


Metnod  of  Authority  Immediate 

Program  Year 
Fund  Source 
Primary  Work  Code 
(nine  digits) 

Carrier  Identifier 
Responsible  Organization 


Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Conventional  PWA  receipts 
Conventional  PWA  issues 
Conventional  PWA  balance 

Method  of  Authority 
Program  Year 
Fund  Source 
Object  Class 

Primary  work  Code  (nine  digits) 
Carrier  Identifier 
Responsible  organization 
Reservation  PWA  receipts 
Reservation  PKl  issues 
Reservation  PWA  balance 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Carrier  Identifier 
Responsible  Organization 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 


/ 


Figure  2.5-10.  - Reimbursable  Order  inquiry  requirements  (concluded) 


2.6  PURCHASE  REQUEST  PROCESS 

JSC  secures  supplies  and  services  from  sources  external 
to  NASA  by  means  of  various  procurement  actions.  These 
actions  are  processed  by  FMD  at  various  stages  of  the 
procurement  process.  The  Purchase  Request  process  (1) 
records  information  concerning  procurement  actions  being 
processed  through  FMD  prior  to  the  actual  commitment  of 
funds  and  (2)  certifies  funds  availability  and  records 
commitment  for  those  procurement  actions  requiring  this 
action  prior  to  completion  of  the  procurement  process. 

2.6.1  Update  Requirements 

2.6. 1.1  Purchase Request.  The  Purchase  Request  (PR) 

can  authorize  several  types  of  procurement  actions  and, 
consequently,  has  different  handling  requirements  based  on 
the  type  of  action  specified.  The  various  PR  types  are 
summarized  below. 

• Regular  PR  - Authorizes  the  administrative 
reservation  of  funds  (commitment)  for  the  items 
listed  on  the  PR  and  the  subsequent  procurement  of 
these  listed  items.  The  Regular  PR  is  the  most 
frequently  used  PR  type. 

• Planning  PR  - Authorizes  preliminary  procurement 
action  to  begin  for  procurement  actions  that  require 
a long  lead  time.  No  commitment  of  funds  is  made, 
and  the  PR  is  used  for  planning  only. 

• Requirements  PR  Authorizes  the  purchase  of  a 

specified  category  of  items  on  an  "as  required" 
basis.  Items  that  can  be  included  on  a Requirements 
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PR  are  aircraft  fuels,  oils,  and  lubricants  and 
categories  of  items  that  are  purchased  through  a 
General  Services  Administration  (GS A)  contractor. 
No  commitment  of  funds  is  made  for  this  PR  type. 

• BPA  Source  PR  - Authorizes  the  establishment  of  a 

Blanket  Purchase  Agreement  (BPA)  between  JSC  and  a 
supplier.  The  supplier  agrees  to  provide  JSC  with  a 
ready  source  for  a specified  category  of  items  and 
agrees  to  supply  the  items  ordered  on  call.  No 
commitment  of  funds  is  made  for  this  PR  type. 

• BPA  Source  PR  for  Technical  Services  - Authorizes 

the  establishment  of  a BPA  contract  for  the 

maintenance,  repair,  etc.  of  specified  items  of 
equipment  with  the  services  provided  on  call.  The 
dollar  limit  specified  on  the  PR  is  committed  during 
the  process. 

Information  from  every  PR  received  in  the  Fund  Control 
Unit  of  FMD  is  to  be  entered  into  the  online  system. 

Requirements  for  this  process  are  described  by  an  action 
classification  (initial,  update,  or  correction)  and  by  the 
data  maintained  for  each  PR  (performance  or  information) . 
The  input,  processing,  and  output  requirements  are  described 
for  each  category  defined. 

2.6.1. 1.1  Initial  recording:  Data  provided  on  all 

PR's  received  in  the  Fund  Control  Unit  must  be  recorded  and 
available  for  later  reference.  Most  PR's  must  undergo  a 
certification  of  available  funds  and/or  the  recording  of 
funds  accounting  data  (performance  data)  while  others 
require  the  recording  of  data  for  information  only.  Regular 
PR's  and  BPA  Source  PR's  for  Technical  Services  require 
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performance  data  recording  while  Planning  PR's,  Requirements 
PR's,  and  BPA  Source  PR's  require  information  data 
recording. 

PERFORMANCE  DATA  REQUIRED 

Input  - Information  that  must  be  input  for  PR's 
requiring  the  recording  of  performance  data  is  obtained  from 
the  Purchase  Request  (JSC  Form  91)  or  from  user  supplied 
information  derived  from  Form  91.  The  input  data  elements 
and  the  data  edits  required  are  shown  in  figure  2.6-1. 

Figure  2.6-2  defines  the  template  required  for  input  of 
these  data  elements.  Most  PR's  will  require  only  one  input 
action.  However,  when  items  specified  on  a PR  have  multiple 
object  classes,  an  input  action  must  take  place  for  each 
object  class  specified.  The  PR  Number  Suffix  must  be  used 
for  all  input  actions  after  the  first  input  action  and 
assigned  in  increasing  numerical  sequence  as  required  by  the 
number  of  different  object  classes.  Dollar  amounts  are 
input  by  object  class  and  the  remaining  data  elements  remain 
the  same  for  each  input  action. 

Processing  - The  initial  input  of  PR's  requiring  the 
recording  of  performance  data  must  not  have  performance  data 
existing  in  the  data  base  for  the  specified  PR  Number  and 
Suffix.  If  the  performance  data  does  exist,  the  requested 
action  is  in  error. 

Availability  of  funds  in  the  funding  PWA  account  must 
be  established  for  the  dollar  amount  input  for  each  Regular 
PR  and  BPA  Source  PR  for  Technical  Services.  This  account 
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Data 

element 

'As  of* 
Date 

Element 

required 

Optional 

Source 

Error 

type 

Input/Edit  requirements 

Error 

code__ 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B101 

Primary  Work 
Code 

Yes 

Form  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Bust  be  nine  digits. 

B 1 70 
B171 
B 1 74 

responsible 

Organization 

Yes 

Form  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  a valid  R0- 

B200 
B20  1 

Object  Class 

Yes 

Form  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  a valid  Object  Class. 

B190 

B191 

Performing 

Organization 

Yes 

Form  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  a valid  Performing  Organization. 

B320 

B321 

Primary  Job 
Code 

Conditional 

Form  91 

Fatal 

Input  if  provided  on  the  source  document.  Must  be 
five  positions.  If  the  first  digit  is  0 or  1,  must 
be  a Centerwide  Job  Code.  Also  validated  with  FS  and 
Performing  Organization. 

B330 
B33  1 
C506 

Secondary 
Job  Code 

Conditional 

Form  91 

Fatal 

Input  if  provided  on  the  source  document  and  a 
Primary  Job  Code  is  input.  Must  be  five  positions. 

If  the  first  digit  is  0 or  1,  must  be  a centerwide  Job 
Code.  Also  validated  with  FS  and  Performing  Orga- 
nization. 

B340 

3341 

B342 

C507 

Method  of 
Authority 

Yes 

User  supplied 
or  Form  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  a valid  MA  but  nof  97. 

B 1 1 0 
Bill 
B 1 1 5 

Program  Year 

Yes 

User  supplied 
or  Fora  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  a valid  PY.  Also  validated  with  FS. 

B 1 20 
C500 

Fund  Source 

Yes 

User  supplied 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  a valid  FS.  Also  validated  with  PY. 

B 1 30 
C500 

Purchase 

Request 

Humber 

Yes 

Form  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  numeric. 

B300 
B30 1 

Purchase 

Pequest 

Humber 

Suffix 

Conditional 

User  supplied 

F<st-?1 

Input  only  for  the  second  and  following  trans- 
actions required  when  multiple  object  classes 
are  specified  on.  a Regular  PR.  Must  be  numeric. 

S3 1 1 

B312 

Commitment 

Dollars 

Yes 

Form  91 

Fatal 

Input  for  all  PR  performance  data  transactions. 
Must  be  numeric  and  greater  than  0. 

BG  00 
B601 
3604 

Type  of 
commitment 

Yes 

User  supplied 

Fatal 

Transaction  modifier*.  Input  as  eithec  Pegular  PR 
or  BP A Technical  Services  PR. 

E040 
B04  1 

For  changes 
only 

No 

None 

Fatal 

Must  not  be  input  for  tnis  transaction. 

5060 

Figure  2.6-1.  - Purchase  Request  performance  data  input  and  edit  requirements. 


♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  OF 
♦ ♦♦'('TEMPLATE  NO.  J1  - PURCHASE  REQUEST  COMMITMENT 
PWC  RESP  ORG  OBJECT  CLASS 

PERF  ORG  PRIMARY  JOB  CODE  SECONDARY  JOB  CODE 

MA PY FS 

PURCHASE  REQUEST  NO.  SUFFIX 

•COMMITMENT  , . ± 

TYPE  OF  COMMITMENT:  REGULAR  PR  _ BP A TECH  SERVICES  PR 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION 


Figure  2.6-2 


Purchase  Request  performance  data  template 


entry  must  be  determined  using  the  MA,  PY,  FS,  funding  BO, 
and  PWC  for  FS  4 and  above  or  funding  Object  Class  for 
current  program  year  FS  1,  2,  or  3.  FS  1,  2,  or  3 for  prior 
years  requires  only  HA,  PY,  FS,  and  funding  RO.  Funding  RO 
and  funding  Object  class  are  converted  as  required  from  the 
RO  and  Object  Class  input  to  the  transaction.  The  PWA 
account  entry  issues  must  be  increased  by  the  input  dollar 
amount  provided  the  balance  is  sufficient  to  fund  the  PR. 

A performance  data  record  must  be  established  for  each 
PR  accepted.  A base  Suffix  must  be  automatically  assigned 
when  a Suffix  is  not  input.  In  the  case  of  multiple  object 
classes  defined  on  the  same  PR,  a performance  data  record 
must  be  established  for  each  input  PR  Number  and  Suffix. 
The  following  data  elements  must  be  included: 

• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes  (if  provided) 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number  and  Suffix 

• Dollar  Amount  (commitment) 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 
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QliJsEUt  “ Section  2.6.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  this  transaction. 

INF0RWATI0N_DATA_RE2UIRED 

In£ut  ~ Data  extracted  from  Planning  PR's,  Requirements 
PR's,  and  BPA  Source  PR's  must  be  input  for  information 
purposes  so  that  the  status  of  every  PR  received  in  FMD  can 
be  established  by  inquiry.  While  the  input  data  elements 
found  on  these  documents  are  the  same  as  those  used  for  the 
creation  of  performance  data,  all  of  the  data  elements  may 
not  be  defined  or  be  valid  (according  to  performance  data 
requirements)  at  the  time  of  input.  Consequently,  the  input 
data  requirements  and  edits  are  less  stringent  and  are  shown 
in  figure  2.6-3.  The  performance  data  edits  will  be  applied 
when  another  document  that  directs  the  commitment  of  funds 
is  received  in  FMD. 

The  template  used  for  the  input  of  information  data  is 
shown  in  figure  2.6-4. 

Processing  - As  this  transaction  is  defined  to  process 
initial  input,  information  data  cannot  already  exist  for  the 
input  PR  Number.  An  information  record  must  be  established, 
and  the  following  elements  must  be  recorded  if  provided  on 
the  source  document. 

• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 
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Data 

element 

Element 

required 

Source 

Error 

£lE§_ 

Input^Edit  requirements 

Error 

code 

•As  of 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

B 1 00 

B 1 0 1 

Primary  Work 
Code 

Conditional 

Form  91 

Fatal 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document.  Must  be  nine  digits. 
No  other  validation  can  be  performed. 

B 1 74 

Responsible 

Organization 

Conditional 

Form  91 

None 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document.  No  other  validation 
can  be  performed. 

None 

Object  Class 

Conditional 

Form  91 

None 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document.  No  other  validation 
can  be  performed. 

None 

Performing 

Organization 

Conditional 

Form  91 

None 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document.  No  other  validation  can 
be  performed. 

None 

Primary  Job 
Code 

Conditional 

Form  91 

Fatal 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document.  Must  be  five  positions. 
If  the  first  digit  is  0 or  1,  must  be  a Centerwide 
Job  Code. 

B33  0 
B331 

Secondary 
Job  Code 

Conditional 

Form  91 

Fatal 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document  and  a Primary  Job  Code 
is  input.  Must  be  five  positions.  If  the  first 
digit  is  0 or  1,  must  be  a Centerwide  Job  Code. 

B340 

B341 

B342 

Method  of 
Authority 

Conditional 

Form  91 

None 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document. 

None 

program  year 

Conditional 

Form  91 

Fatal 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document.  Must  be  numeric.  No 
other  validation  can  be  performed. 

B 121 

Fund  Source 

Conditional 

Form  91 

Fatal 

Input  for  PR  information  data  transactions  if  pro- 
vided on  the  source  document.  Must  be  numeric.  No 
other  validation  can  be  performed. 

B139 

Purchase 

Request 

Number 

Yes 

Form  91 

Fatal 

Input  for  all  PR  information  data  transactions. 
Must  be  numeric. 

B300 

B301 

Purchase 

Request 

Number 

Suffix 

NO 

None 

F atal 

Must  not  be  input  for  this  transaction. 

B312 

Figure  2*6-3.  - Purchase  Reguest  information  data  input  and  edit  requirements. 
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Data 

Element 

Error 

Error 

element 

required 

Source 

Input/Edit  requirements 

code 

Information 

Dollars 

Conditional 

Form  91 

Fatal 

Input  for  Planning  PR 
only.  Must  be  numeric 

information  data 
and  greater  than 

transaction 

0. 

B601 

B604 

B605 

Type  of 
information 

Yes 

User  supplied 

Fatal 

Transaction  modifier, 
following: 

Input  as  one  of 

the 

B050 

B051 

• Planning  PR 

• Requirements  PR 

• BPA  PR 


For  changes  No  None  Fatal  Must  not  be  input  for  this  transaction  * B061 

only 


Figure  2.6-3 


Purchase  Request  information  data  input  and  edit  requirements  (concluded) 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦ ♦♦♦•TEMPLATE  NO.  J2  - PURCHASE  REQUEST  INFORMATION 

PWC  _ RESP  ORG OBJECT  CLASS  

PERF  ORG  PRIMARY  JOB  CODE  SECONDARY  JOB  CODE  

MA  __  PY FS  

PURCHASE  REQUEST  NO.  

INFORMATION  $ , , • 

TYPE  OF  INFORMATION:  PLANNING  PR  _ REQUIREMENTS  PR  _ BPA  PR 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


• Primary  and  Secondary  Job  Codes 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number 

• Originating  Organization  Request  Number 

• Planning  Dollars  (Planning  PR’s  only) 

The  transaction  information  is  also  recorded  on  a 
transaction  history. 

Out£ut  - Section  2.6.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  transaction. 

2. 6. 1.1. 2 Update  and  correction:  After  the  initial 

recording  of  performance  data  or  information  data,  the 
capability  to  update  or  correct  the  data  must  be  provided. 
Changes  specified  by  means  of  a source  document  will  be 
recorded  as  update  transactions.  • Those  changes  made  as  a 
result  of  erroneous  input  of  a data  element  will  be  defined 
to  be  correction  transactions,  and  no  source  document  is 
associated  with  this  transaction.  The  requirements  for  the 
actual  data  changes  are  identical  for  both  transactions,  and 
every  data  element  is  subject  to  either  transaction. 

PERFORMANCE  DATA  CHANGE 


Input  - The  PR  Number  and  Suffix  identify  the  unique 
data  element  set  to  which  the  changes  will  be  made.  If  a 
change  is  applicable  to  the  base  Suffix,  only  the  PR  Number 
is  required  input,  and  the  base  Suffix  is  generated*  If 
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multiple  suffix  inputs  have  been  defined  and  the  change  is 
applicable  to  a suffix  other  than  the  base  Suffix,  both  the 
PR  Number  and  Suffix  are  required  input.  The  type  of  PR  and 
type  of  change  (update  or  correction)  are  also  identified. 
Data  elements  to  be  changed  are  input  as  required  and  can 
include  any  of  the  elements  defined  for  initial  input. 
Figure  2.6-5  shows  the  possible  data  element  changes  and  the 
edits  required  for  these  elements. 

The  Purchase  Request  performance  data  template  is  used 
to  input  the  required  data  and  is  illustrated  in  figure  2.6- 

2. 


EE2£§ssing  - Processing  requirements  for  update  and 
correction  transactions  vary  according  to  the  data  elements 
being  changed.  As  the  transactions  are  defined  to  change 
existing  data,  an  error  message  is  to  be  output  if  the 
record  designated  by  the  PR  Number  and  Suffix  does  not 
exist.  For  those  elements  that  have  no  effect  on  the  funds 
availability  process  (Performing  Organization,  Primary  and 
Secondary  Job  Codes,  and  Originating  Organization  Request 
Number) , the  data  element  can  be  updated  directly. 

Changes  to  the  commitment  dollars,  MA,  PY,  FS,  RO,  PWC 
(if  FS  4 or  above)  and  Object  Class  (FS  1,  2,  or  3)  have  an 
effect  on  the  Fund  Control  accounts  and  thus  have  more 
extensive  processing  requirements.  A decrease  in  commitment 
dollars  requires  that  the  dollar  amount  of  the  decrease  be 
subtracted  from  the  performance  data  commitment  and  also 
from  the  issues  of  the  funding  PWA  account  entry.  A dollar 
increase  to  commitment  requires  that  a funds  availability 
check  be  made  for  the  amount  of  the  increase.  Changes  to 
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Figure  2-6-5 


Purchase 


Error  Error 

type  Input/Edit  requirements  gode_ 

Fatal  Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 


Fatal  Input  only  when  a change  transaction  is  used  to  up-  B171 

date  this  element.  Must  be  nine  digits.  B174 


Fatal  Input  only  when  a change  transaction  is  used  to  up-  B201 

date  this  element.  Must  be  a valid  RO. 


Fatal  Input  only  when  a change  transaction  is  used  to  up-  B191 

date  this  element.  Must  be  a valid  Object  Class. 


Fatal  Input  only  when  a change  transaction  is  used  to  up-  B321 

date  this  element.  Must  be  a valid  Performing 
Organization. 

Fatal  Input  only  when  a change  transaction  is  used  to  up-  B330 

date  this  element.  Must  be  five  positions.  If  the  B331 

first  digit  is  0 or  1,  must  be  a Centerwide  Job  Code.  C509 

Also  valid  with  FS  and  Performing  Organization  de- 
fined for  PR  performance  data  being  changed  or  with 
updated  values  if  either  or  both  are  changed  in  the 
transaction. 


Fatal  Input  only  when  a change  transaction  is  used  to  up-  B340 

date  this  element.  A Primary  Job  Code  must  already  B341 

exist  for  PR  performance  data  being  changed  or  be  B343 

input  as  a part  of  this  transaction.  Must  be  five  C510 


positions.  If  the  first  digit  is  0 or  1,  must  be  a 
Centerwide  Job  Code.  Also  validated  with  FS  and 
Performing  Organization. 


Fatal  Input  only  when  a change  transaction  is  used  to  up-  Bill 

date  this  element.  Must  be  a valid  MA  but  not  97.  B115 


Fatal  Input  only  when  a change  transaction  is  used  to  up-  B121 

date  this  element.  Must  be  a valid  PY.  Also  must  B122 

be  validated  with  FS  defined  for  PR  performance  * C508 

data  being  changed  or  with  updated  values  if  either 
or  both  are  changed  in  this  transaction. 


est  performance  data  change  input  and  edit  requirements. 
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element 

Element 

reauired 

Source 

Error 

Fund  Source 

Conditional 

User  supplied 

Fatal 

or  other 
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document 


Purchase 
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Yes 

Form  91 
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update 
document 
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Purchase 

Request 

Number 

Suffix 

Conditional 

User  supplied 

Fatal 

Commitment 

Dollars 

Conditional 

Form  91 
or  other 
update 
document 

Fatal 

Type  of 
commitment 

No 

None 

Fatal 

For  changes 
only 

Yes 

User  supplied 

Fatal 

Inpsat  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  FS.  Also 
oust  be  validated  with  PY  defined  for  PR  perfor- 
mance data  being  changed  or  with  updated  values 
if  either  or  both  are  changed  in  this  transaction. 

Input  for  all  change  transactions.  Must  be  numeric. 


Input  only  when  a change  transaction  is  to  be 
applied  to  a suffix  other  than  the  base  suffix. 
Must  be  numeric. 


Input  as  a net  change  only  when  a change  trans- 
action is  used  to  update  this  element.  Must 
be  numeric  and  not  equal  to  0. 


Must  not  be  input  for  this  transaction. 


Transaction  modifier.  Input  as  either  'update'  if 
change  being  made  is  directed  by  documentation  or 
•correction'  if  change  is  being  made  because  of 
erroneous  initial  input. 


Error 

code 

C508 


B300 

B301 


B311 


B601 

B602 


B060 


B060 

B062 


Figure  2.6-5.  - Purchase  Reguest  performance  data  change  input  and  edit  requirements  (concluded). 


any  of  the  other  data  elements  listed  above  result  in  a 
change  of  the  funding  PWA  account  entry.  As  a result,  the 
entire  commitment  amount  must  be  subtracted  from  the  issues 
of  the  original  funding  PWA  account  entry,  the  availability 
of  funds  checked,  the  appropriate  account  entry  issues 
increased,  and  the  changed  data  element  posted  in  the 
performance  data. 

To  satisfy  audit  trail  requirements,  the  transaction 
must  be  recorded  in  a transaction  history. 

Output  - Section  2.6.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 


INFORMATION_DATA_CHANGE 

Input  - The  PE  Number  identifies  the  unique  set  of 
information  data  to  which  the  update  or  correction  is  to  be 
made.  The  type  of  PR  and  type  of  change  (update  or 
correction)  must  also  be  identified.  Any  of  the  data 
elements  that  are  included  in  the  information  data  can  be 
changed  and  are  input  as  required.  These  data  elements  and 
the  required  edits  are  defined  in  figure  2.6-6. 

The  Purchase  Request  information  data  template  is  used 
to  input  the  required  data  and  is  illustrated  in  figure  2.6- 

4. 


Processing  - Processing  requirements  for  the  update  and 
correction  of  information  data  are  very  limited.  As  no 
budgetary  data  is  affected  by  the  changes,  the  data  set  to 
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Data 

element 

Element 

required 

Source 

Error 

tY£§_ 

Input/Edit  requirements 

Error 

code 

•As  of' 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

B 1 00 
Bill 

Primary  Work 
Code 

Conditional 

Form  9 1 
or  other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  nine  digits.  No  other 
validation  can  be  performed. 

B 1 74 

Responsible 

Organization 

Conditional 

Form  91 
or  other 
update 
document 

None 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  No  other  validation  can  be  per- 
formed. 

None 

Object  Class 

Conditional 

Form  91 
or  other 
update 
document 

None 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  No  other  validation  can  be  per- 
formed. 

None 

Performing 

Organization 

Conditional 

Form  91 
or  other 
update 
document 

None 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  No  other  validation  can  be  per- 
formed. 

None 

Primary  Job 
Code 

Conditional 

Form  91 
or  other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  five  positions.  If  the 
first  digit  is  0 or  1,  must  be  a Centerwide  Job  Code. 

B330 

B331 

Secondary 
Job  Code 

Conditional 

Form  91 
or  other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  A Primary  Job  Code  must  already 
exist  for  the  PR  information  data  being  changed  or 
be  input  as  a part  of  this  transaction.  Must  be 
five  positions.  If  first  digit  is  0 or  1,  must  be 
Centerwide  Job  Code. 

B340 

B341 

B343 

Method  of 
Authority 

Conditional 

User  supplied. 
Form  91, 
or  other 
update 
document 

None 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element. 

None 

Program  Year 

Conditional 

Form  91 
or  other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  numeric.  No  other 
validation  can  be  performed. 

B121 

Figure  2.6-6.  .-  Purchase  Request  information  data  change  input  and  edit  requirements. 
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Error 


Fund  Source 

Conditional 
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document 

Fatal 

Purchase 

Request 
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document 

Fatal 

Purchase 

Request 

Number 

Suffix 

No 

None 

Fatal 

Information 

Dollars 

Conditional 

Form  91 
or  other 
update 
document 

Fatal 

Type  of 
information 

No 

None 

Fatal 

For  changes 
only 

Yes 

User  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up-  B139 

date  this  element.  Must  be  numeric.  No  other 
validation  can  be  performed. 


Input  for  all  change  transactions.  Must  be  numeric.  B300 


Must  not  be  input  for  this  transaction.  B312 


Input  only  when  a change  transaction  is  used  to  up-  B601 

date  this  element.  Must  be  numeric  and  not  equal  E602 

to  0. 

Must  not  be  input  for  this  transaction.  B061 

Transaction  indicator.  Input  as  either  ‘update*  if  B061 

change  being  made  is  directed  by  documentation  or  B062 

•correction'  if  change  is  being  made  because  of 
erroneous  initial  input. 


- Purchase  Request  information  data  change  input  and  edit  requirements  (concluded) . 


Figure  2.6-6. 


which  the  change  must  be  effected  is  located  and  the  data 
elements  changed. 

Out£ut  - Section  2.6.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 


2.6. 1.2  Bequest for Fund_Citation.  The  Request  for 

Fund  Citation  (JSC  Form  1043)  serves  two  purposes.  First, 
and  most  frequent,  it  is  the  official  document  for  the 
conversion  of  planning  dollars  into  actual  commitment 
dollars.  Second,  it  reverses  the  commitment  of  funds.  As 
the  requirements  for  these  functions  differ,  they  will  be 
discussed  separately. 

2.6. 1.2.1  Commitment:  As  previously  stated,  no 
commitment  of  funds  in  the  PR  planning  stage  exist. 
However,  no  official  procurement  action  can  be  completed 
until  the  actual  commitment  is  made,  and  the  Request  for 
Fund  Citation  authorizes  that  commitment  action. 

IHEUt  ~ The  data  elements  required  for  the  fund 
citation  of  planning  dollars  are  extracted  from  two  sources: 
the  Request  for  Fund  Citation  and  the  information  data  for 
the  applicable  Planning  PR.  These  data  elements  and  the 
applicable  edit  requirements  are  shown  in  figure  2.6-7.  The 
template  required  for  input  of  the  data  elements  extracted 
from  the  Request  for  Fund  Citation  is  shown  in  figure  2.6-8. 

If  there  are  changes  required  to  the  data  extracted 
from  the  information  data  of  the  Planning  PR  being  cited  in 
order  to  complete  the  commitment  requested,  these  changes 
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Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Extracted  from  the  PR  information  data  recorded  for  B178 

the  Planning  PR  cited. 

Extracted  from  the  PR  information  data  recorded  for  B203 

the  Planning  PR  cited.  Bust  be  a valid  RO.  B204 

Extracted  from  the  PR  information  data  recorded  for  B193 

the  Planning  PR  cited.  Must  be  a valid  Object  Class.  B194 

Extracted  from  the  PR  information  data  recorded  for  B322 

the  Planning  PR  cited.  Must  be  a valid  Performing  B323 

Organization. 

If  present,  extracted  from  the  PR  information  data  B332 

recorded  for  the  Planning  PR  cited.  Validated  with  C509 

FS  and  Performing  Organization. 

If  present,  extracted  from  the  PR  information  data  B343 

recorded  for  the  Planning  PR  cited.  Validated  with  C51G 

FS  and  Performing  Organization. 

Extracted  from  the  PR  information  data  recorded  for  B118 

the  Planning  PR  cited.  Must  be  a valid  MA  but  not 

97. 

Extracted  from  the  PR  information  data  recorded  for  B124 

the  Planning  PR  cited.  Must  be  a valid  PY.  Also  B125 

validated  with  FS.  C508 

Extracted  from  the  PR  information  data  recorded  for  B140 

the  Planning  PR  cited.  Must  be  a valid  FS.  Also  C508 

validated  with  PY. 

Input  for  all  Fund  Citation  transactions.  Must  be  B300 

numeric.  B301 

Must  not  be  input  for  this  transaction.  B312 


Figure  2.6-7 


Request  for  Fund  Citation  input  and  edit  requirements 
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Optional 

User  supplied 

None 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction  Is 
a correction. 

None 

Figure  2.6-7.  - Request  for  Fund  Citation  input  and  edit  requirements  (concluded) . 
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****IFMS  SEPTEMBER  30,  1974  AS  OF  / 

♦♦♦♦TEMPLATE  NO.  J3  - FUND  CITATION 

PURCHASE  REQUEST  NO,  SUFFIX  • 

COMMITMENT  OR  REVERSAL  $ , . ± 

TYPE  OF  TRANSACTION:  FUND  CITATION  _ REVERSAL  _ 

EXTENT:  PARTIAL  _ COMPLETE  _ 

CORRECTION 


Figure  2.6-8.  - Fund  Citation/Commitment  Reversal  template 
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must  be  made  using  a PR  information  data  update  transaction 
prior  to  the  execution  of  this  transaction. 

Procgssing  - Because  the  Reguest  for  Funds  Citation 
requires  the  commitment  of  planning  dollars,  the  input  PR 
Number  must  be  an  existing  Planning  PR. 

The  funding  PWA  account  entry  must  be  determined  using 
the  M A , PY,  FS,  funding  RO,  and  PWC  for  FS  4 and  above  or 
funding  Object  Class  for  current  program  year  FS  1,  2,  or  3. 
FS  1,  2,  ot  3 for  prior  years  requires  only  HA,  PY,  FS,  and 
funding  RO.  Funding  RO  and  funding  Object  Class  are 
converted  as  required  from  the  RO  and  Object  Class  input  to 
the  trasaction.  The  funding  PWA  account  entry  issues  must 
be  increased  by  the  input  dollar  amount  provided  the  balance 
is  sufficient  to  fund  the  commitment. 

Requirements  for  the  recording  of  the  commitment  of 
funds  vary  according  to  the  prior  transactions  on  this  PR. 
If  no  prior  transactions  have  occurred,  a performance  data 
record  is  established  with  the  following  data  elements: 

• Primary  Work.  Code 

• Responsible  organization 

• object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number  and  Suffix 

• Dollar  Amount  (commitment) 


2.6-22 


If  a prior  commitment  has  been  made  and  all  accounting 
data  is  identical,  the  commitment  dollars  can  be  updated  by 
the  additional  amount  specified  in  the  transaction.  Should 
there  be  accounting  data  differences,  a new  performance  data 
record  must  be  established  under  the  next  higher  PR  Number 
Suffix.  This  suffix  will  be  automatically  generated,  and 
its  value  will  be  displayed  as  a part  of  the  transaction 
output. 

Partial  commitments  must  cause  the  planning  dollars 
contained  in  the  information  data  for  the  Planning  PR  to  be 
updated  to  reflect  the  dollars  remaining  in  the  planning 
stage.  Complete  commitments  must  close  out  the  Planning  PR. 
Finally,  the  transaction  must  be  recorded  in  a transaction 
history  in  order  to  satisfy  audit  trail  requirements. 

QUtEMi:  “ Section  2.4.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  this  transaction. 

2.6. 1.2.2  Reversal:  The  reversal  of  any  commitment 
can  be  accomplished  via  Form  1043  regardless  of  the  PR 
type.  Using  this  procedure,  the  reversal  cannot  be  of  an 
amount  that  would  decrease  the  commitment  below  the 
obligation  amount. 

lEElii  ~ The  template  to  be  used  for  the  Commitment 
Reversal  transaction  is  shown  in  figure  2.6-8.  Figure  2.6-9 
contains  a list  of  data  elements  that  must  be  input  for  the 
Commitment  Reversal  transaction. 
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Form  1043 
or  user 
supplied 

Fatal 

Input  when  the  Commitment  Reversal  transaction  is 
applicable  to  a suffix  other  than  the  base  suffix 
or  the  PR.  Must  be  numeric. 

Dollar 

Amount 

Yes 

Form  1043 

Fatal 

Input  for  all  Commitment  Reversal  transactions. 
Must  be  numeric  and  not  be  equal  to  0. 

B6  00 
B601 
B602 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Transaction  indicator.  Input  for  all  Commitment 
Reversal  transactions.  Input  as  ‘reversal.* 

B0 1 0 
B011 

B070 

B071 

Extent 

Yes 

Form  1043 

Fatal 

Transaction  modifier.  Input  for  all  Commitment 
Reversal  transactions.  Input  as  either  ’complete 

or  ‘partial. * 

Correction 

Optional 

User  supplied 

None 

transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  a transaction  is  a 

None 

correction. 

Figure  2.6-9. 


- Commitment  Reversal  input  ana  edit  requirements. 


Processing  - Because  the  transaction  directs  the 
reversal  of  a commitment,  performance  data  identified  by  the 
input  PR  Number  and  Suffix  must  exist  in  the  data  base.  The 
reversal  amount  cannot  be  greater  than  the  commitment  being 
reversed  nor  can  it  reduce  the  commitment  amount  below  the 
obligation  amount.  If  the  transaction  is  designated  as  a 
complete  reversal,  the  reversal  amount  must  egual  the 
current  commitment  amount. 

The  dollar  amount  of  the  commitment  reversal  must  be 
returned  to  the  PWA  account  entry  that  funded  the  commitment 
and  the  PWA  account  entry  issues  be  reduced  by  the  specified 
reversal  amount.  The  applicable  subaccount  entry  is 
identified  by  MA,  PY,  FS,  funding  RO,  and  a five-digit  PWC 
for  FS  4 and  above  or  funding  Object  Class  for  current 
program  year  FS  1,  2,  or  3.  FS  1,  2,  or  3 for  prior  years 
requires  only  MA,  PY , FS,  and  funding  RO.  This  data  is 
obtained  from  the  accounting  data  recorded  for  the  PR  Number 
and  Suffix  to  which  the  reversal  is  applied.  The  RO  and 
Object  Class  contained  in  the  PR  accounting  data  must  be 
converted  to  funding  RO  and  funding  Object  Class  as 
required.  A negative  account  entry  balance  must  not  occur. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  input  and  correction  transactions  will  be  identified 
in  the  transaction  history. 

Output  - Section  2.6.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Commitment  Reversal  transaction. 


2.6-25 


2.6. 1.3  FSS Purchase Record.  The  request  for  the 

commitment  of  funds  for  orders  placed  with  a GSA  contractor 
and  authorized  by  a Requirements  PR  is  made  on  a FSS 
Purchase  Record  (JSC  Form  708) . A certification  of 
available  funds  must  be  made  and  the  performance  data 
recorded  in  the  data  base.  This  section  discusses  the 
requirements  for  the  initial  input  of  the  data.  The  update 
and  correction  requirements  are  the  same  as  the  requirements 
for  the  Regular  PR's  and  BPA  Technical  Services  PR's.  These 
requirements  are  discussed  as  performance  data  changes  in 
section  2.6.1. 1.2. 

Input  - Figure  2.6-10  contains  a list  of  the  elements 
that  must  be  input  and  the  edits  that  must  be  performed  for 
the  FSS  Purchase  Record  transaction.  Because  the  required 
input  is  very  similar  to  the  PR  input,  the  same  template  is 
used  and  is  shown  in  figure  2.6-2. 

Processing  - Because  a FSS  Purchase  Request  order  is 
authorized  by  a Requirements  PR,  the  Requirements  PR 
specified  by  the  input  PR  Number  must  exist  in  the  data 
base. 

The  funding  PWA  account  entry  must  be  determined  using 
the  MA,  PY,  FS,  funding  RO,  and  PWC  for  FS  4 and  above  or 
funding  Object  Class  for  current  program  year  FS  1,  2,  or  3. 
FS  1,  2,  or  3 for  prior  years  requires  only  MA,  PY,  FS,  and 
funding  RO.  Funding  RO  and  funding  Object  Class  are 
converted  as  required  from  the  RO  and  Object  Class  input  to 
the  transaction.  The  funding  PWA  account  entry  issues  must 
be  increased  by  the  input  dollar  amount  provided  the  balance 
is  sufficient  to  fund  the  commitment. 
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Data 

element 

Element 

required 

Source 

Error 

'As  of' 
Date 

Optional 

User  supplied 

Fatal 

Primary  Work 
Code 

Yes 

Form  708 

Fatal 

Responsible 

Organization 

Yes 

Form  708 

Fatal 

Object  Class 

Yes 

Form  708 

Fatal 

Performing 

Organization 

Yes 

Form  708 

Fatal 

Primary  Job 
Code 

Conditional 

Form  708 

Fatal 

Secondary 
Job  Code 

Conditional 

Form  708 

Fatal 

Method  of 
Authority 

Yes 

User  supplied 
or  Form  708 

Fatal 

Program  Year 

Yes 

User  supplied 
or  Form  708 

Fatal 

Fund  Source 

Yes 

User  supplied 

Fatal 

Originating 

Organization 

Bequest 

Number 

Conditional 

Fora  708 

Non- 

fatal 

Purchase 

Request 

Number 

Yes 

Form  708 

Fatal 

Error 

Input/Edit  requirements  ££Lift- 

Date  providing  for  the  backdating  of  transactions,  B100 

Input  only  when  a transaction  date  other  than  the  8101 

system  date  is  desired.  When  input*  Bust  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  FSS  transactions.  Must  be  nine  digits  8170 

r B171 

B174 

Input  for  all  FSS  transactions.  Must  be  a valid  B200 

R0;  B201 

Input  for  all  FSS  transactions.  Must  be  a valid  B190 

Object  Class.  B191 

Input  for  all  FSS  transactions.  Must  be  a valid  B320 

Performing  Organization.  B321 

Input  if  provided  on  the  source  document.  Must  be  B330 

five  positions.  If  the  first  digit  is  0 or  1,  must  B331 

be  a centerwide  Job  Code.  Also  validated  with  FS  C506 

and  Performing  Organization. 

Input  if  provided  on  the  source  document  and  a Pri-  B340 

mary  Job  Code  is  input.  Must  be  five  positions.  B341 

If  the  first  digit  is  0 or  1f  must  be  a Centerwide  B342 

Job  Code.  Also  validated  with  FS  and  Performing  C507 

organization. 

Input  for  all  FSS  transactions.  Must  be  a valid  HA  B110 

but  not  97.  Bill 

B 1 15 

Input  for  all  FSS  transactions.  Must  be  a valid  PY.  B120 

Also  validated  with  FS.  B121 

C500 

Input  for  all  FSS  transactions.  Must  be  a valid  FS.  B130 

Also  validated  with  PY.*  C50G 

Input  for  FSS  transactions  if  provided  on  the  None 

source  document.  No  validation  can  be  made* 

Input  for  all  FSS  transactions.  Must  be  numeric.  B300 


Figure  2.6-10,  - FSS  input  and  edit  requirements. 


Data 

element 

Element 

required 

Source 

Error 

£xes_ 

Input/Edit  requirements 

Error 

code 

Purchase 

Request 

Number 

Suffix 

No 

None 

Fatal 

Must  not  be 

input  for  this  transaction. 

B31 2 

Dollar 

Amount 

Yes 

Form  708 

Fatal 

Input  for  all  FSS  transactions.  Must  be  numeric 
and  greater  than  0. 

B600 

B601 

B604 

Type  of 
commitment 

Yes 

User  supplied 

Fatal 

Transaction 

modifier.  Must  specify  *FSS*. 

B040 

B041 

For  changes 
only 

No 

None 

Fatal 

Must  not  be 

input  for  this  transaction. 

B060 

Figure  2.6-10.  - FSS  input  and  edit  requirements  (concluded). 


Because  many  Federal  Supply  System  (FSS)  orders  can  be 
issued  against  the  same  PR  number,  individual  orders  must  be 
assigned  to  separate  performance  data  records.  The  PR 
Number  Suffix  is  to  be  used  to  maintain  the  separation  and 
will  be  automatically  increased  to  the  next  available  number 
during  transaction  processing.  A performance  data  record 
must  be  established  for  the  transaction  using  the  suffix 
generated.  The  following  elements  must  be  included  in  the 
record: 

• Primary  Work  Code 

• Responsible  Organization 

• object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes  (If  provided) 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number  and  Suffix 

• Dollar  Amount  (commitment) 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 

Output  “ Section  2.4.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  FSS  Purchase  Record  transaction. 


2.6.2  Output  Message  Requirements 


Figures  2.6-11  through  2.6-15  contain  a list  of  output 
message  requirements.  Figure  2.6-16  contains  a correlation 
of  output  messages  by  the  Purchase  Request  process 
transaction. 


2.6.3  Inquiry  Requirements 

Figure  2.6-17  contains  a list  of  inquiry  input  data 
elements  and  response  data  elements  required  for  the 
Purchase  Request  process. 

2.6.4  Report  Requirements 

The  report  requirements  are  an  integral  part  of  the 
Open  Commercial  Order  Status  report  described  in  section 
2.19.6, 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  PR  Process  Section  report  described 
in  section  2.19.7. 
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Code 


Mgssage 


PR 

PERFORMANCE 

TRANSACTION 

- 

INITIAL 

REGULAR 

PR 

**** 

PR 

PERFORMANCE 

TRANSACTION 

- 

INITIAL 

BPA  TECH 

SERVICES 

**** 

PR 

PERFORMANCE 

TRANSACTION 

- 

INITIAL 

FSS 

**** 

PR 

PERFORMANCE 

TRANSACTION 

- 

UPDATE 

**** 

PR 

PERFORMANCE 

TRANSACTION 

- 

CORRECTION 

* *** 

PR 

INFORMATION 

TRANSACTION 

- 

INITIAL 

PLANNING 

PR 

**** 

PR 

INFORMATION 

TRANSACTION 

- 

INITIAL 

REQUIREMENTS  PR 

PR 

INFORMATION 

TRANSACTION 

- 

INITIAL 

BPA  PR 

**** 

PR 

INFORMATION 

TRANSACTION 

- 

UPDATE 

PR 

INFORMATION 

TRANSACTION 

- 

CORRECTION 

****  fund  citation  partial  commitment  transaction 

****'•  FUND  CITATION  COMPLETE  COMMITMENT  TRANSACTION 

****  FUND  CITATION  PARTIAL  REVERSAL  TRANSACTION 

****  fund  CITATION  COMPLETE  REVERSAL  TRANSACTION 

B 01 0 TYPE  OF  TR ANACTION  NOT  SPECIFIED 

B0 11  MULTIPLE  TYPES  OF  TRANSACTION  SPECIFIED 

B040  TYPE  OF  COMMITMENT  NOT  SPECIFIED 

B 04 1 MULTIPLE  TYPES  OF  COMMITMENT  SPECIFIED 

B 050  TYPE  OF  INFORMATION  NOT  SPECIFIED 

B051  MULTIPLE  TYPES  OF  INFORMATION  SPECIFIED 

B060  BOTH  FOR  CHANGES  ONLY  AND  TYPE  OF  COMMITMENT  MUST  NOT  BE  SPECIFIED 

B061  BOTH  FOR  CHANGES  ONLY  AND  TYPE  OF  INFORMATION  MUST  NOT  BE  SPECIFIED 

B062  BOTH  UPDATE  AND  CORRECTION  MUST  NOT  BE  SPECIFIED 
B 070  EXTENT  NOT  SPECIFIED 

BO 7 1 BOTH  PARTIAL  AND  COMPLETE  MUST  NOT  BE  SPECIFIED 

Figure  2.6-11.  - Purchase  Request 
transaction-begun  messages. 

Code  Msssage 

A 000  TRANSACTION  COMPLETE 

Figure  2.6-12.  - Purchase  Request 
transaction-complete  messages. 
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Message 


Code 

B 1 00  ' AS  OF  ' DATE  INVALID 

B 1 0 1 'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE 

B 1 1 0 MA  NOT  ENTERED 

Bill  MA  INVALID 

Bl 1 5 MA  MUST  NOT  BE  97 

B 1 1 8 MA  NOT  DEFINED  IN  PR  INFORMATION  DATA 

B 1 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

B 1 24  PY  NOT  DEFINED  IN  PR  INFORMATION  DATA 

B 1 25  PY  MUST  BE  58  TO  CURRENT  FISCAL  YEAR 

B 1 30  FS  NOT  ENTERED 

B 1 39  FS  INVALID 

B 1 40  FS  NOT  DEFINED  IN  PR  INFORMATION  DATA 
Bl 70  PWC  NOT  ENTERED 

B 1 71  PWC  INVALID 

B 1 7 4 PWC  MUST  BE  9 DIGITS 

B 1 7 8 PWC  NOT  DEFINED  IN  PR  INFORMATION  DATA 
B 1 90  OBJECT  CLASS  NOT  ENTERED 

B 1 9 1 OBJECT  CLASS  INVALID 

Bl 93  OBJECT  CLASS  NOT  DEFINED  IN  PR  INFORMATION  DATA 

B 1 94  OBJECT  CLASS  INVALID 

B200  RESPONSIBLE  ORGANIZATION  NOT  ENTERED 

B 201  RESPONSIBLE  ORGANIZATION  INVALID 

B203  RESPONSIBLE  ORGANIZATION  NOT  DEFINED  IN  PR  INFORMATION  DATA 

B2 04  RESPONSIBLE  ORGANIZATION INVALID 

B300  PURCHASE  REQUEST  NUMBER  NOT  ENTERED 
B30 1 PURCHASE  REQUEST  NUMBER  INVALID 


Figure  2.6-13.  - Purchase  Request  data  element 
edit  error  messages. 


Message 


-4T 

\<i  ' pj/ 


Code 

B311  SUFFIX  INVALID 

B312  SUFFIX  MUST  BE  BLANK 

B320  PERFORMING  ORGANIZATION  NOT  ENTERED 

B321  PERFORMING  ORGANIZATION  INVALID 

B322  PERFORMING  ORGANIZATION  NOT  DEFINED  IN  PR  INFORMATION  DATA 

B323  PERFORMING  ORGANIZATION  INVALID 

B330  PRIMARY  JOB  CODE  INVALID 

B331  PRIMARY  JOB  CODE  MUST  BE  CENXERWIDE  JOB  CODE 
B 332  PRIMARY  JOB  CODE  NOT  DEFINED  IN  PR  INFORMATION  DATA 
B34C  SECONDARY  JOB  CODE  INVALID 

B341  SECONDARY  JOB  CODE  MUST  BE  CENTERWIDE  JOB  CODE 

B 342  PRIMARY  JOB  CODE  BLANK  SO  SECONDARY  JOB  CODE  MUST  BE  BLANK 

B 343  PRIMARY  JOB  CODE  NOT  DEFINED  SO  SECONDARY  JOB  CODE  MUST  BE  BLANK 

B600  $ AMOUNT  NOT  ENTERED 

B601  $ AMOUNT  INVALID 

B602  $ AMOUNT  MUST  NOT  BE  ZERO 

B604  $ AMOUNT  MUST  BE  GREATER  THAN  ZERO 

B605  $ AMOUNT  MUST  BE  BLANK 

C500  PY,  FS  COMBINATION  INVALID 

C506  FS,  PERF  ORG*  *? RIM ARY  JOB  CODE  COMBINATION  INVALID 
C507  FS,  PERF  ORG,  SECONDARY  JOB  CODE  COMBINATION  INVALID 
C508  PY  , FS  COMBINATION  INVALID 

C509  FS  , PERF  ORG  PRIMARY  JOB  CODE  COMBINATION  INVALID 

C5 1 0 FS  , PERF  ORG  SECONDARY  JOB  CODE  COMBINATION  INVALID 


Figure  2.6-13.  - Purchase  Request  data  element 
edit  error  messages  (concluded) . 


M 
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^ i n ' - U r 


Code 


A210  SUFFIX  GENERATED  AS 

A211  INFORMATION  $ LESS.  THAN  ZERO 
PURCHASE  REQUEST  NO. 


Figure  2.6-14.  - Purchase  Request 
processing  advisory  messages. 
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PWC 


Code  figssaag 

D 1 40  PWA  RECORD  NOT  FOUND 

MA  __  PY FS  __  RO 

OBJECT  CLASS  CARRIER  ID  SUB  ID 

D 1 42  PHA  ISSUES  INSUFFICIENT 

MA PY FS RO PMC 

OBJECT  CLASS  CARRIER  ID  SUB  ID 

ISSUES  , , . UPDATE  , , . 

D143  PWA  BALANCE  INSUFFICIENT  TO  INCREASE  ISSUES 

MA PY FS  __  RO PMC 

OBJECT  CLASS  CARRIER  ID  SUB  ID 

BALANCE  , . UPDATE  $_, , , 

D150  CARRIER  RECORD  NOT  FOUND 

MA PY FS CARRIER  ID 

D 1 52  CARRIER  ISSUES  INSUFFICIENT 

MA PY FS CARRIER  ID 

ISSUES  , . UPDATE  , , . 

D153  CARRIER  BALANCE  INSUFFICIENT  TO  INCREASE  ISSUES 

MA  __  PY FS CARRIER  ID 

BALANCE  $_, , . UPDATE  $_, , 

D180  PERFORMANCE  DATA  RECORD  NOT  FOUND 

PURCHASE  REQUEST  NO.  SUFFIX 

D 1 81  PERFORMANCE  DATA  RECORD  ALREADY  EXISTS 

PURCHASE  REQUEST  NO.  SUFFIX 

D 1 82  COMMITMENT  $ INSUFFICIENT 

PURCHASE  REQUEST  NO.  SUFFIX 

COMMITMENT  , UPDATE  $_, , , 

D183  COMMITMENT  $ LESS  THAN  OBLIGATION  $ 

COMMITMENT  $_, , , UPDATE  $_, , , 

NEH  COMMITMENT  , , . OBLIGATION 

D 1 84  REVERSAL  $ NOT  EQUAL  TO  COMMITMENT  $ 

COMMITMENT  $_, , , . REVERSAL  $_, , 

D 1 90  INFORMATION  RECORD  NOT  FOUND 
PURCHASE  REQUEST  NO. 

D 1 91  INFORMATION  RECORD  ALREADY  EXISTS 
PURCHASE  REQUEST  NO. 


Figure  2.6-15 


Purchase  Request  processing  error  messages 
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Transaction 
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BBBBBB3BB 

001111111 
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bbbcbbbb 
11111111 
22223347 
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PR_Perf ormance 

Initial  Regular  PR 

Initial  BPA  Technical  Services  PR 

Initial  FSS 

Update/Correction 
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Initial  Requirements  PR 
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Update/Correction 
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X X 


X X X 
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X X X X X XX 
X X X X X XX 
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X XX 
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Initial  Planning  PR  X 
Initial  Requirements  PR  X 
Initial  BPA  PR  X 
Update/Correction  X 
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Reversal 


X X X X X X X 
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X 
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XXX 


Figure  2.6-16.  - Purchase  Request  messages  by  transaction. 
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111111 
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PH_Perf  ormance 

Initial  Regular  PR 

Initial  BPA  Technical  Services  PR 

Initial  FSS 

Update/Correction 

EE_Information 
Initial  Planning  PR 
Initial  Requirements  PR 
Initial  BPA  PR 
Update/Correction 
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Fijura  2.6-1b.  - Purchase  Heguest  messages:  !,y  transaction  (cohcluiei)  . 


IX  X X X 


5.  lotion 


Eiee 


Timing 


Sufficient  funds 
commit 


Purchase  Request 
information  data 


Purchase  Request 


Purchase  Request 
suffix  assigned 


Ingut^data  elements 


Response  data  elements 


to 


Item 


status 


Item 


status  Item 


highest  Item 


Method  of  Authority  Immediate 

Program  Year 
Fund  Source 
Responsible  Orga- 
nization 

Primary  Work  Code 
(nine  digits) 

Object  Class 
Dollar  Amount 

Purchase  Request  Immediate 

Number 


Purchase  Request  Immediate 

Number  . 

Suffix  (when  other 
than  base  suffix 
status  required) 


Purchase  Request  Immediate 

Number 


Method  of  Authority 
Program  Year 
Fund  Source 

Responsible  Organization 
Primary  Work  Code  (five  digits)  or 
funding  Object  Class 
Message:  'Dollars  are  available'  or 

'Dollars  are  not  available* 
P W A balance 

Purchase  Request  Number 
Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Object  Class 
Performing  Organization 
Primary  dob  Code 
Secondary  Job  Code 
Information  dollars 

Purchase  Request  Number 
Suffix 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits,) 

Responsible  Organization 

Object  Class 

Performing  Organization 

Primary  Job  Code 

Secondary  Job  Code 

Commitment 

Obligation 

Cost 

Disbursement 

Purchase  Request  Number 
Highest  suffix  assigned 


Figure  2.6-1?.  - Purchase  Request  inquiry  requirements. 


2.7  OBLIGATION  PROCESS 


The  Obligation  process  includes  the  recording  of  JSC 
obligations  resulting  from  contracts,  orders,  grants. 
Blanket  Purchase  Agreement  (BPA)  calls,  and  Government  Bill 
of  Lading  (GBL)  shipments.  These  obligations  are  the  result 
of  agreements  to  procure  supplies  and  services  through  non- 
NASA  sources.  Other  obligations  are  recorded  in  the  Travel 
process  (section  2,12)  and  in  the  Payroll  process  (section 
2.  14)  . 


2.7.1  Update  Requirements 

Update  requirements  for  the  Obligation  process  can  be 
described  in  three  categories:  (1)  contracts,  orders, 
grants,  and  miscellaneous  obligations,  (2)  BPA's,  and  (3) 
GBL's.  Information  received  in  the  Fund  Control  Unit  of  FMD 
permits  the  recording  of  the  obligation  against  prior 
commitment,  the  recording  of  both  the  commitment  and 
obligation,  and  the  recording  of  the  commitment,  obligation, 
and  cost  as  required. 

2.7. 1.1  Contracting and Miscellaneous Obligation 

documents . Contracting  documents  are  those  documents  used 
by  JSC  to  establish  contracts,  orders,  and  grants.  The 
forms  used  include  Award/Contract  (SF26) , Order  for  Supplies 
or  Services  (SF1379),  Amendment  of  Solicitation/Modification 
of  Contract  (SF30) , Construction  Contract  (SF23) , 
Architectural  and  Engineering  Contract  (SF765) , 
Solicitation,  Offer,  and  Award  (SF33) , Research  Grant  (NASA 
Form  1463),  NASA  - Defense  Purchase  Request  (NASA  Form  523), 
and  the  PR  Overlay  (modified  JSC  Form  91)  . Each  of  these 


forms  supply  data  concerning  the  accounting  data  required 
for  the  obligation,  the  amount  of  the  obligation,  signatures 
of  JSC  contracting  officials  and  officials  of  the  contractor 
or  supplier,  and  other  required  information. 

Miscellaneous  Obligation  documents  are  not  signed, 
contracting  documents  but  rather  are  administrative 
modifications  that  the  obligation  of  a specified  amount 
requires  for  such  things  as  aircraft  fuel,  utilities 
services,  and  GSA  supplied  services.  These  miscellaneous 
obligations  are  generally  periodically  recurring  events 
(usually  monthly) . 

2.7.1. 1.1  Initial  recording:  The  information 
contained  on  Contracting  and  Miscellaneous  Obligation 
documents  received  in  the  Fund  Control  Unit  must  be  recorded 
as  a part  of  the  performance  data  maintained  by  IFMS.  In 
addition,  contract  level  information  must  be  recorded  for 
all  contracts  and  grants.  Input  of  data  for  a new  contract, 
order,  grant,  or  the  first  of  a repeating  miscellaneous 
obligation  establishes  the  obligation  amount  while  the  input 
of  amendments  to  contracts,  orders,  or  grants  or  the 
periodic  miscellaneous  obligation  updates  the  obligation 
amount  already  recorded. 

Input  - Information  that  must  be  input  for  the 
Contracting  and  Miscellaneous  Obligation  Documents 
transaction  is  obtained  from  the  Contracting  or 
Miscellaneous  Obligation  document,  from  the  user,  or  in  some 
instances,  from  the  financial  copy  of  the  Purchase  Request 
(JSC  Form  91)  retained  at  the  time  of  funds  commitment.  The 
input  data  elements  and  data  edits  required  are  shown  in 


2.7-2 


figure  2.7-1.  Figure  2.7-2  specifies  the  document  type 
codes  permitted.  Figure  2.7-3  defines  the  template  required 
for  input  of  these  data  elements. 

E£°£e§sinq  ~ Processing  requirements  for  the  normal 
obligation  differ  from  the  requirements  for  the  Running  PR 
obligation.  The  Running  PR  obligation  is  the  obligation  of 
several  contracts  under  the  same  PR.  The  normal  obligation 
requires  that  an  open  performance  data  record  exist  in  the 
data  base  for  the  specified  PR  Number  and  Suffix.  The 
Running  PR  obligation  requires  that  an  open  performance  data 
record  exist  for  the  specified  PR  Number  and  base  Suffix. 
If  the  required  performance  data  record  does  not  exist  or  if 
the  record  is  closed,  the  transaction  is  in  error. 

The  normal  obligation  requirements  specify,  at  a 
minimum,  that  the  obligation  field  of  the  performance  data 
record  specified  by  the  input  PR  Number  and  Suffix  be 
updated.  If  a positive  dollar  amount  is  input,  that  value 
must  be  added  to  the  obligation  field.  If  the  total 
obligation  exceeds  the  commitment  made  for  the  specified  PR 
Number  and  Suffix,  funds  in  the  amount  of  the  difference 
between  the  obligation  and  the  commitment  must  be  available 
in  order  to  complete  the  transaction.  A table  of 
preestablished  limits  must  be  checked  to  determine  whether 
the  additional  funds  can  be  obtained  automatically  from  the 
funding  PWA  account.  If  the  additional  funds  exceed  the 
limits  established  in  the  table,  processing  must  be  halted 
and  an  error  message  provided  to  the  user.  If  the  required 
amount  is  less  than  the  limit,  the  funds  must  be 
automatically  obtained  and  an  advisory  message  that 
specifies  the  amount  obtained  from  the  PWA  account  must  be 
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Data 

element 

Element 

required 

Source 

Error 

tZES- 

* As  of' 
Date 

Optional 

User  supplied 

Fatal 

Contract/ 

Order 

Number 

Yes 

Contract/ 

Order 

document 

Fatal 

Amendment 

Number 

Conditional 

Contract/ 

Order 

document 

Fatal 

Contract 

Schedule 

Number 

Conditional 

User  supplied 

Fatal 

Document 
type  code 

Conditional 

User  supplied 

Fatal 

Contractor 
name  code 

Conditional 

Contract/ 

Order 

document 

N on- 
fatal 

purchase 

Request 

Number 

Yes 

Contract/ 

Order 

document 

Fatal 

Purchase 

Request 

Number 

Suffix 

Conditional 

Form  91 

Fatal 

Punning 

Purchase 

Fequest 

indicator 

Conditional 

User  supplied 

None 

Obligation 

Dollars 

Yes 

Contract/ 

Order 

document 

Fatal 

Extent  of 
Obligation 

Yes 

Con  tract/ 

Order 

document 

Fatal 

Correction 

No 

None 

None 

Figure 

2*7- 1 • - Contracting  and  Miscellaneou 

Input/Edit  requirements 


Error 
cod  e_ 


Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  he  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  Contract/Order  Obligation  transactions. 
Positions  1 and  2 must  be  a valid  Contract/Order  pre- 
fix. 

Input  if  it  is  an  amendment  or  change  to  an  existing 
contract  or  order.  Must  be  numeric. 


Input  if  the  second  or  greater  year  of  a multi-year 
contract.  Must  be  alphabetic. 


Input  to  define  the  type  of  document  being  processed. 
See  figure  2.7-2  for  the  definition  of  these  codes. 

Input  for  the  basic  order/contract  only.  Must  be 


Input  for  all  Contract/Order  Obligation  transactions. 


Input  when  a PR  has  commitments  established  under 
suffixes  other  than  the  base  suffix,  and  the  obli- 
gation is  to  be  applied  to  a suffix  other  than  the 
base  suffix.  Must  be  numeric. 

Transaction  modifier.  Input  only  when  an  automatic  in- 
crementation of  the  PR  Number  Suffix  is  required  for 
Running  PR's. 


Input  for  all  Contract/Order  Obligation  transactions. 
Must  be  numeric  and  not  equal  to  0. 


Transaction  modifier.  Input  as  either  'partial'  if 
the  action  is  applicable  only  to  the  Obligation 
amount  or  'complete*  if  the  Commitment  amount  is  to 
be  adjusted  to  be  made  equal  to  the  Obligation  amount. 

Must  not  be  input  for  this  transaction. 


Obligation  Documents  initial  input. and  edit  requirements. 


Commercial 

N/A 

A 

C 

D 

K 
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N 

0 
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4 
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6 
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DescriptrQn 
Basic  order/contract 
Amendment 
Change  order 
Delivery  order 
Call  order 

Letter  contract  or  let 
ter  amendment 

Modification 

Change  notice 

Task  order 

Supplemental  agreement 
TWX 


Figure  2.7-2.  - Document  type  codes. 


****IFMS  SEPTEMBER  30 , 1974  AS  OF  / / 

****TEMPLfrTE  NO,  K1  - CONTRACTING  & MISC.  OBLIGATION  DOCUMENTS  ' 

CONTRACT/ORDER  NO.  AMENDMENT  NO.  CONTRACT  SCHEDULE  NO. 

DOCUMENT  TYPE  CODE  _ CONTRACTOR  NAME  CODE  

PURCHASE  REQUEST  NO,  SUFFIX  RUNNING  PR 

OBLIGATION  $ , , • * 

EXTENT  OF  OBLIGATION:  COMPLETE  _ PARTIAL  _ 

CORRECTION  _ 


Figure  2.7-3. 


Contracting  and  Miscellaneous  Obligation 


Documents 


template. 


~ 3> 
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provided  to  the  user.  The  funding  PWA  account  entry  must  be 
determined  using  HA , PY,  FS,  funding  RO,  and  PWC  for  FS  4 
and  above  or  funding  Object  Class  for  the  current  program 
year  FS  1,  2,  or  3.  FS  1,  2,  or  3 for  prior  years  requires 
only  MA,  PY,  FS,  and  funding  RO.  MA,  PY,  FS,  and  PWC  can  be 
obtained  directly  from  the  performance  data  record  while  the 
funding  RO  and  funding  Object  Class  must  be  converted  from 
the  recorded  RO  and  Object  Class.  The  PWA  account  entry 
issues  and  the  commitment  must  be  increased  by  the 
additional  dollars  required  provided  the  PWA  account  entry 
balance  is  sufficient  to  fund  that  amount.  If  the  total 
obligation  is  less  than  the  commitment  and  the  complete 
obligation  is  specified,  the  commitment  must  be  reduced  by 
the  amount  required  to  make  the  commitment  equal  the 
obligation.  That  amount  also  must  be  subtracted  from  the 
funding  PWA  account  entry  issues  (increasing  the  balance) . 
If  a negative  dollar  amount  is  input,  the  obligation  field 
must  be  reduced.  However,  the  reduction  roust  not  reduce  the 
obligation  below  the  cost  recorded  for  the  PR  Number  and 
Suffix  being  processed.  The  specification  of  a complete 
obligation  requires  that  the  commitment  be  reduced  by  the 
amount  necessary  to  make  the  commitment  equal  to  the 
obligation.  The  funding  PWA  account  entry  issues  also  must 
be  reduced  by  a like  amount  (increasing  the  balance) . 

The  Running  PR  obligation  requirements  specify  the 
automatic  generation  of  the  next  higher  suffix  available  for 
this  PR  Number  and  the  generation  of  a performance  data 
record  for  the  generated  suffix  if  a partial  obligation  is 
specified.  An  advisory  message  must  be  generated  to  inform 
the  user  of  the  generated  value.  The  suffix  must  be 
recorded  on  the  source  document  immediately  following  the  PR 
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Number  so  that  the  number  is  readily  available  if  required 
for  subsequent  costing  and  disbursement  actions.  The 
following  data  elements  are  obtained  from  the  performance 
data  record  having  the  base  Suffix: 

• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number  and  generated  Suffix 

The  base  suffix  performance  data  record  commitment  field 
must  be  reduced  by  the  amount  of  this  obligation,  and  that 
amount  must  be  recorded  in  the  commitment  and  obligation 
fields  of  the  performance  data  record  having  the  generated 
suffix.  If  the  obligation  amount  is  greater  than  the 
commitment  recorded  in  the  base  suffix  performance  data 

record,  a table  of  preestablished  limits  must  be  checked  to 
determine  whether  the  additional  funds  can  be  obtained 

automatically  from  the  funding  PWA  account.  If  the 
additional  funds  exceed  the  limits  established  in  the  table, 
processing  must  be  halted  and  an  error  message  provided  to 
the  user.  If  the  required  amount  is  less  than  the  limit, 
the  base  suffix  commitment  must  be  reduced  to  0,  and  the 
additional  funds  necessary  must  be  obtained  from  the  funding 
PWA  account  entry  and  the  issues  of  that  account  entry 
increased  provided  the  balance  is  sufficient  to  fund  the 

required  amount.  An  advisory  message  must  inform  the  user 
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of  the  amount  of  funds  obtained  from  the  funding  PWA 
account.  The  specification  of  a complete  obligation 
requires  the  update  of  the  base  suffix  performance  data 
record  obligation  field.  If  the  obligation  is  greater  than 
the  commitment,  the  additional  funds  necessary  must  be 
obtained  from  the  funding  PWA  account  entry,  the  issues  of 
that  account  entry  increased  provided  the  balance  is 
guff icient  to  fund  the  required  amount,  and  that  additional 
amount  added  to  the  commitment  field.  If  the  obligation  is 
less  than  the  commitment,  the  commitment  field  must  be 
reduced  by  the  amount  necessary  to  make  the  commitment  equal 
the  obligation.  The  funding  PWA  account  entry  issues  also 
must  be  reduced  by  a like  amount  (increasing  the  balance  for 
that  entry) . 

Both  the  normal  and  the  Running  PR  obligation 
requirements  specify  that  the  following  data  elements  be 
recorded  in  the  performance  data  record  used  to  record  the 
obligation  amount. 

• Contractor  name  code 

• Contract/Order  Number 

• Amendment  Number  (if  provided) 

• Schedule  Number  (if  provided) 

• Document  type  code 

Additional  processing  requirements  exist  when  the 
obligation  being  recorded  is  applicable  to  a contract  or 
grant.  If  a contract  record  does  not  exist  in  the  data  base 
for  the  input  contract  or  grant  number,  one  must  be  created. 
The  following  data  elements  must  be  recorded  in  the  record: 
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Contract  or  grant  number 
Contractor  name  code 

Type  of  contract  (commercial  or  government) 

Cost  accrual  type  (recorded  as  automatic  if  the 
obligation  is  < $150,000) 

Contract  Obligation  Dollars 

Nonexcluded  Object  Class  Obligation  Dollars  (all 
object  classes  except  2200,  4000,  5000,  and  6001 
series) 

If  the  contract  record  already  has  been  established,  the 
obligation  dollars  in  the  transaction  are  added  to  or 
subtracted  from  the  contract  obligation  dollars  and  as 
required  from  the  nonexcluded  Object  Class  obligation 
dollars  for  positive  and  negative  obligation  dollars 
respectively.  In  addition,  the  Contract  Schedule  Number  and 
Contract  Amendment  Number  are  recorded  as  applicable.  To 
satisfy  audit  trail  requirements,  the  transaction  is 
recorded  in  a transaction  history. 

Output  - Section  2.7.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 


2. 7. 1.1. 2 Correction:  After  the  initial  recording  of 
the  obligation  data  for  the  Contracting  and  Miscellaneous 
Obligation  documents,  the  capability  to  correct  any 
erroneous  input  must  be  provided. 

Ingut  * The  PR  Number  and  Suffix  identify  the  unique 
data  element  set  to  which  the  correction  is  to  be  made.  If 
a change  is  applicable  to  the  base  Suffix,  only  the  PR 
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Number  is  required  input.  If  the  change  is  applicable  to 
any  suffix  other  than  the  base  Suffix,  both  the  PR  Number 
and  Suffix  are  required  input.  Corrections  required  because 
of  an  erroneous  PR  Number,  Suffix,  or  Contract/Order  Number 
(when  a contract  record  exists)  must  be  corrected  by  a 
reversal  of  the  original  transaction  having  the  erroneous 
data  and  the  input  of  a complete  transaction  (all  data 
elements)  with  the  correct  data.  v*  gure  2.7-4  shows  the 
possible  data  element  corrections  and  edits  required.  The 
Contracting  and  Miscellaneous  Obligation  Documents  template 
is  used  to  input  the  required  data  and  is  illustrated  in 
figure  2.7- 1 . 

* Processing  requirements  for  the  correction 
transaction  vary  according  to  the  data  elements  being 
changed.  As  the  transaction  is  defined  to  change  existing 
data,  an  error  message  is  to  be  output  if  the  record 
designated  by  the  PR  Number  and  Suffix  does  not  exist. 

Changes  to  the  Amendment  Number,  Contract  Schedule 
Number,  Contractor  name  code,  and  document  type  codes  are 
overlaid  in  the  designated  performance  data  record.  If  the 
performance  data  record  being  corrected  has  an  associated 
contract  record  (contract  or  grant  only) , the  contract 
record  must  be  updated  also.  The  Contractor  name  code  can 
be  overlaid.  The  Amendment  Number  and  Contract  Schedule 
Number  are  updated  if  the  changed  number  is  greater  than  the 
current  value  recorded  in  the  contract  record.  The  contract 
type  field  must  be  updated  if  a change  in  the  document  type 
codes  indicates  a change  from  'commercial'  to  'government' 


or  vice  versa. 
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Input/Edit  requirements 

Error 

code 

'AS  of' 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

5100 

3101 

Contract/ 

Order 

Number 

Conditional 

Contract/ 

Order 

Number 

Fatal 

Input  only  when  a correction  transaction  is  used 
to  update  this  element.  Positions  1 and  2 must  be 
a valid  Contract/Order  prefix. 

E361 

A mendment 
Number 

Conditional 

Contract/ 

Order 

Number 

Fatal 

Input  only  when  a correction  transaction  is  used  to 
update  this  element.  Must  be  numeric. 

B370 

B371 

Contract 

Scnedule 

Number 

Conditional 

User  supplied 

Fatal 

input  only  when  a correction  transaction  is  used  to 
update  this  element.  Must  be  alphabetic. 

5350 

Document 
type  code 

Conditional 

User  supplied 

Fatal 

Input  only  when  a correction  transaction  is  used  to 
update  this  element.  See  figure  2.7-2  for  the  defi- 
nition of  these  codes. 

b7  90 

ro 

Contractor 
naif  code 

Conditional 

Contract/ 

Order 

document 

N on- 
f atal 

Input  only  when  a correction  transaction  is  used  to 
update  this  element.  Must  be  numeric. 

8 4 00 

7-12 

Purchase 

Request 

Number 

Yes 

Contract/ 

Order 

document  or 
user  supplied 

Fatal 

Input  for  all  Contract/Order  Obligation  correction 
transactions. 

B300 

B301 

Purchase 

Pequest 

Pumher 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  when  the  correction  transaction  is  to  be  ap- 
plied to  a suffix  other  than  the  base  suffix.  Must 
be  numeric. 

B311 

Punning 

Purchase 

Pequest 

indicator 

Ho 

None 

Fatal 

Must  not  be  input  for  the  correction  transaction. 

B430 

Obligation 

Dollars 

Conditional 

Contract/ 

Order 

document 

Fatal 

Input  as  a net  change  only  when  a correction  trans- 
action is  used  to  update  this  element.  Must  be 
numeric  and  not  egual  to  0. 

B621 

B622 

Extent  of 
Obligation 

Conditional 

Contract/ 

Order 

document 

Fatal 

Transaction  modifier.  Input  as  either  'partial'  or 
'complete*  when  the  correction  transaction  is  used 
to  update  the  obligation  Dollars. 

C421 

Correction 

Yes 

User  supplied 

Fatal 

Transaction  modifier.  Input  for  all  Contract/Order 
Obligation  correction  transactions. 

None 

Figure  2.7-4.  - Contracting  and  Miscellaneous  Obligation  Documents  correction  input  and  edit  requirements. 


A correction  to  the  obligation  dollars  affects  the 
performance  data  record,  may  affect  the  Fund  Control 
accounts,  and,  if  the  change  is  applicable  to  a PE  for  a 
contract  or  grant,  affects  the  contract  record.  The 
processing  requirements  are  controlled  by  the  sign  of  the 
dollars  and  for  Fund  Control  account  and  performance  data 
record  requirements  by  the  extent  of  obligation  specified. 
If  a positive  dollar  amount  is  input  and  either  partial  or 
complete  extent  of  payment  is  specified,  that  amount  must  be 
added  to  the  obligation  field  of  the  performance  data 
record.  If  the  total  obligation  exceeds  the  commitment  made 
for  the  specified  PR  Number  and  Suffix,  funds  in  the  amount 
of  the  difference  between  the  obligation  and  the  commitment 
must  be  available  in  order  to  complete  the  transaction.  A 
table  of  preestablished  limits  must  be  checked  to  determine 
whether  the  additional  funds  can  be  obtained  automatically 
from  the  funding  PWA  account.  If  the  additional  funds 
exceed  the  limits  established  in  the  table,  processing  must 
be  halted  and  an  error  message  provided  to  the  user.  If  the 
required  amount  is  less  than  the  limit,  the  funding  PWA 
account  entry  issues  and  the  commitment  must  be  increased  by 
the  additional  dollars  required  provided  the  funding  PWA 
account  entry  balance  is  sufficient  to  fund  that  amount.  An 
advisory  message  must  inform  the  user  of  the  amount  of  funds 
obtained  from  the  funding  PWA  account.  If  the  total 
obligation  is  less  than  the  commitment  and  the  complete 
obligation  is  specified,  the  commitment  must  be  reduced  by 
the  amount  required  to  make  the  commitment  equal  to  the 
obligation.  That  amount  must  also  be  subtracted  from  the 
funding  PWA  account  entry  issues  (increasing  the  balance) . 
If  a negative  dollar  amount  is  input,  the  obligation  field 
must  be  reduced.  However,  the  reduction  must  not  reduce  the 
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obligation  below  the  cost  recorded  for  the  PR  Number  and 
Suffix  being  processed.  The  specification  of  a complete 
extent  of  payment  requires  that  the  commitment  be  reduced  by 


the  amount  necessary  to  make  the  commitment  equal  the 
obligation.  The  funding  PWA  account  entry  issues  also  must 
be  reduced  by  a like  amount  (increasing  the  balance) . If 
the  performance  data  record  being  corrected  has  an 
associated  contract  record,  the  Contract  Obligation  Dollars 
are  increased  or  decreased  as  required  by  the  sign  of  the 
dollar  correction.  In  addition,  the  nonexcluded  Object 
Class  obligation  dollars  are  increased  or  decreased  if  the 
applicable  object  class  is  not  in  the  2200,  4000,  5000,  or 
6001  series.  To  satisfy  audit  trail  requirements,  the 
tranaction  is  recorded  in  a transaction  history. 


Output  - Section  2.7.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 


2. 7. 1.2  BP A Call documents.  BPA  Call  documents  are 

those  documents  used  by  JSC  to  record  the  calls  for  the 
purchase  of  goods  or  services  made  against  a BPA.  The  forms 
used  are  the  BPA  Call  Transaction  (JSC  Form  1128)  and  the 
BPA  Call  Transaction  for  Inventory  Purchases  (JSC  Form 
1979) . These  forms  supply  the  accounting  data  required,  the 
dollar  amount,  the  description  of  the  goods  or  services 
ordered,  and  the  signature  of  the  ordering  officer. 

2. 7. 1.2.1  Initial  recording:  The  information 
contained  on  the  BPA  Call  documents  received  in  the  Fund 
Control  Unit  must  be  recorded  as  a part  of  the  performance 
data  maintained  in  IFMS.  BPA  calls  for  the  purchase  of 
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goods  (Regular  BPA  calls)  require  that  a funds  availability 
check  be  performed.  BPA  calls  for  technical  services  (BPA 
Tech  Services  calls)  have  funds  committed  when  the  basic  BPA 
is  signed  and  normally  do  not  require  an  additional  funds 
availability  check. 

£GEE£  ~ Information  that  must  be  input  for  any  BPA  call 
is  obtained  from  the  BPA  Call  document.  The  input  data 
elements  and  data  edits  required  are  shown  in  figure  2.7-5. 
The  template  required  for  input  of  these  elements  is  shown 
in  figure  2.7-6. 

Because  the  identity  of  each  BPA  call  must  be 
maintained  in  the  system,  a unique  PR  Number  Suffix  will  be 
automatically  generated  and  used  to  record  the  BPA  call 
transaction, 

" Because  all  BPA  call  transactions  are 
controlled  by  the  PR  Number  used  to  establish  the  BPA,  that 
PR  Number  must  already  exist  in  the  data  base.  The  first 
Regular  BPA  call  for  a specific  PR  Number  must  have  an 
information  record  for  that  PR  Number.  The  remainder  of  the 
Regular  BPA  calls  and  all  BPA  Tech  Services  calls  must  have 
a performance  data  record  for  the  specified  PR  Number  and 
base  Suffix.  If  the  required  records  do  not  exist  or  if  the 
performance  data  record  having  the  base  Suffix  is  closed, 
the  transaction  is  in  error. 

Other  processing  requirements  are  controlled  by  the 
type  of  BPA  call  being  processed  (Regular  or  Tech  Services) , 
the  sign  of  the  dollar  amount  in  the  transaction,  and  the 
extent  of  obligation  (partial  or  complete) . The  automatic 
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Element 

required 


Source 


Data 

element 


Error 

Input/Edit  requirements 


•As  of* 
Date 

Optional 

User  supplied 

Fatal 

P rimary 
Work  Code 

Yes 

BPA  document 

Fatal 

Pesponsibie 

Organization 

Yes 

BPA  document 

Fatal 

Object  Class 

Yes 

BPA  document 

Fatal 

Performing 

Organization 

Yes 

BPA  document 

Fatal 

Primary  Job 
Code 

Conditional 

BPA  document 

Fatal 

Secondary 
Job  Code 

Conditional 

BPA  document 

Fatal 

Method  of 
Authority 

Yes 

BPA  document 

Fatal 

Program  Year 

Yes 

BPA  document 

Fatal 

Fund  Source 

Yes 

BPA  document 

Fatal 

Purchase 

Request 

Number 

Yes 

BPA  document 

Fatal 

Purchase 

Request 

Generated 

System 

supplied 

None 

Number 

Suffix 


Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  Shen  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  BP A transactions.  Must  be  nine  digits 
and  a valid  PWC. 


Input 

HO. 

for 

all 

BPA 

transactions. 

Must 

be 

a 

valid 

Input 

for 

all 

BPA 

transactions. 

Must 

be 

a 

valid 

Object 

. Class. 

Input 

for 

all 

BPA 

transactions. 

Must 

be 

a 

valid 

Performing  Organisation. 


Input  if  it  is  provided  on  the  source  document. 

Must  be  five  positions.  If  the  first  position  is 
0 or  1,  must  be  a Centerwide  Job  Code  and  validated 
with  FS  and  Performing  Organization. 

Input  if  it  is  provided  on  the  source  document  and 
a Primary  Job  Code  is  input.  If  the  first  position 
is  0 or  1,  must  be  a Centerwide  Job  Code  and  vali- 
dated with  FS  and  Performing  Organization. 

Input  for  all  BPA  transactions.  Must  be  a valid 
MA  bet  not  97. 


Input  for  all  BPA  transactions.  Must  be  a valid  PY. 
Also  validated  with  FS. 


Input  for  all  BPA  transactions.  Must  be  a valid 
FS.  Also  validated  with  PY. 


Input  for  all  BPA  transactions. 


Automatically  generated  for  all  BPA  transactions. 
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B174 
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B 1 90 
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C507 
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B 1 1 0 
Bill 
B115 
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B 1 30 
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C507 

B300 

B301 


None 


Figure  2.7-5.  - Blanket  Purchase  Agreement  initial  input  and  edit  requirements 
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BP A document 
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BP A document 
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Document 
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System 
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BP A document 
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not  equal  to  0. 
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Type  of 

Yes 

BP A document 

Fatal 

Must  be  input  as  either  "Regular"  for  Regular  BPA 
calls  or  "Tech  Services"  for  BPA  Technical  Services 
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calls. 

C420 
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Yes 

BP  A document 

Fatal 
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For  changes 
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None 
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Must  not  be  input  for  initial  BPA  transactions. 

None 

only 


Figure  2.7-5.  - 


Blanket  Purchase  Agreement  initial  input  and  edit  requirements  (concluded) , 


****IFMS  SEPTEMBER  30,  1974  AS  OF 
****T£MPLATE  NO.  K2  - BP A xl k 

PWC  998000000  RESP  ORG  JF  OBJECT  CLASS  

PERF  ORG  JF9 3 PRIMARY  JOB  CODE  SECONDARY  JOB  CODE  

MA  00  PY FS  _9 

PURCHASE  REQUEST  NO.  SUFFIX  

CONTRACT/ORDER  NO.  CALL  NO.  

COMMITMENT/OBLIGATION  $ , , . ± 

TYPE  OF  BPA : REGULAR  _ TECH  SERVICES  _ 

EXTENT  OF  OBLIGATION:  PARTIAL  _ COMPLETE  _ 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 

Note:  Since  a large  number  of  BPA  calls  are  for  Inventory 

Purchases,  the  template  will  be  displayed  with  the 
constant  information  indicated.  Individual  fields 
can  be  modified  at  the  terminal  or  all  constant  in- 
information can  be  removed  from  the  terminal  screen 
via  a push  of  a button  at  the  terminal  and  all  fields 

supplied  by  the  cleric.  . 


Figure  2.7-6.  - Blanket  Purchase  Agreement  template. 

2.7-18 


generation  of  the  suffix  can  occur  only  when  a positive 
dollar  amount  is  entered. 

Regular  BPA  Calls 

The  specification  of  a Regular  BPA  call  with  a positive 
dollar  amount  entered  in  the  transaction  requires  that  the 
funding  PWA  account  entry  have  a sufficient  balance  to  fund 
the  call.  If  the  balance  is  sufficient,  the  funding  PWA 
account  entry  issues  are  increased  by  the  dollar  amount  of 
the  call.  The  first  call  for  a specific  PR  Number  requires 
the  generation  of  a performance  data  record  for  the  base 
Suffix  with  the  following  data  elements: 

• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes  (if  supplied) 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number  and  base  Suffix 

• Contract/Order  Number 

• Document  type  code 

The  commitment  and  the  obligation  fields  of  the  base  suffix 
performance  data  record  are  increased  by  the  dollar  amount 
of  the  call  if  the  extent  of  commitment  for  the  first  or  any 
other  call  is  specified  to  be  complete. 
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If  the  extent  of  commitment  is  specified  to  be  partial# 
the  PR  Number  Suffix  must  be  automatically  incremented  and  a 
performance  data  record  generated  for  that  suffix  with  the 
following  data  elements: 

• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes  (if  supplied) 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number  and  generated  Suffix 

• Contract/Order  Number 

• Document  type  code 

• Commitment  Dollars 

• obligation  Dollars 

BPA_Tech_Services_Calls 

The  specification  of  a Tech  Services  call  with  a 
positive  dollar  amount  entered  in  the  transaction  requires 
that  funds  already  committed  for  the  specified  PR  Number 
under  the  base  Suffix  be  used  in  the  transaction.  If  there 
is  insufficient  commitment  under  the  base  Suffix,  a table  of 
preestablished  limits  must  be  checked  to  determine  whether 
the  additional  funds  can  be  obtained  automatically  from  the 
funding  PWA  account.  If  the  additional  funds  exceed  the 
limits  established  in  the  table,  processing  must  be  halted 
and  an  error  message  provided  to  the  user.  If  the  required 
amount  is  less  than  the  limit,  the  additional  funds  required 


must  be  obtained  from  the  funding  PWA  account  entry  and  the 
entry  issues  and  the  base  Suffix  commitment  increased  by 
that  amount  provided  the  entry  balance  is  sufficient  to  fund 
the  required  amount.  An  advisory  message  must  inform  the 
user  of  the  amount  of  funds  obtained  from  the  funding  PWA 
account.  A partial  extent  of  obligation  requires  that  the 
PR  Number  Suffix  be  automatically  incremented  and  a 
performance  data  record  generated  for  that  suffix  with  the 
following  data  elements: 

• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes  (if  supplied) 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• PR  Number  and  generated  Suffix 

• Contract/Order  Number 

• Document  type  code 

• Commitment  Dollars 

• Obligation  Dollars 

The  Commitment  Dollars  under  the  base  Suffix  must  be  reduced 
by  the  dollar  amount  recorded  under  the  generated  Suffix.  A 
complete  extent  of  obligation  requires  that  the  dollar 
amount  be  recorded  in  the  base  suffix  obligation  field.  If 
the  obligation  is  less  than  the  commitment,  the  commitment 
must  be  reduced  by  the  amount  necessary  to  make  the 
commitment  equal  to  the  obligation*  The  funding  PWA  account 
entry  issues  are  decreased  by  this  same  amount  (increasing 
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the  balance) . To  satisfy  audit  trail  requirements,  the 
transaction  must  be  recorded  in  a transaction  history. 

Output  - Section  2.7.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 

2.7. 1.2.2  Update  and  correction:  After  the  initial 
recording  of  the  BPA  call,  the  capability  to  update  and 
correct  the  data  must  be  provided.  Changes  specified  by 
means  of  a source  document  will  be  recorded  as  an  update 
transaction.  Those  changes  made  as  a result  of  erroneous 
input  of  a data  element  will  be  defined  as  a correction 
transaction.  The  requirements  for  the  actual  data  changes 
are  identical. 

lEEiit  * The  PR  Number  and  Suffix  identify  the  unique 
data  set  to  which  the  change  is  to  be  made.  If  a change  is 
applicable  to  the  base  Suffix,  only  the  PR  Number  is 
required  input.  If  the  change  is  applicable  to  any  suffix 
other  than  the  base  Suffix,  both  the  PR  Number  and  Suffix 
are  required  input.  Required  changes  to  the  PR  Number  and 
Suffix  must  be  corrected  by  a reversal  of  the  dollar  amount 
assigned  to  the  performance  data  record  having  the  PR  Number 
and  Suffix  to  be  changed  and  by  the  input  of  the  complete 
transaction  (all  data  elements)  with  the  changed  data. 
Figure  2.7-7  shows  the  possible  data  element  corrections  and 
data  edits  required.  The  BPA  template  required  for  input  of 
these  data  elements  is  illustrated  in  figure  2.7-6. 

Processing  “ Processing  requirements  vary  according  to 
the  data  elements  being  changed.  As  the  transaction  is 
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Data 

element 

Element 

required 

Source 

Error 

* As  of' 
Date 

Optional 

User  supplied 

Fatal 

Primary  Work 
Code 

Conditional 

BPA  document 
or  other 
updaf e 
documen  t 

Fatal 

Responsible 

Organization 

Conditional 

BPA  document 
or  otner 
update 
document 

Fatal 

Object  Class 

Conditional 

BPA  document 
or  other 
update 
document 

Fatal 

Performing 

Organization 

Conditional 

BPA  document 
or  other 
update 
document 

Fatal 

Primary  Job 
Code 

Conditional 

BPA  document 
or  other 
update 
document 

Fatal 

Secondary 
Job  Code 

Conditional 

BPA  document 
or  other 
update 
documen  t 

Fatal 

Error 

Input/Edit  requirements  code_ 

Date  providing  for  the  backdating  of  transactions.  3100 

Input  only  when  a transaction  date  other  than  the  3101 

system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  only  when  a change  transaction  is  used  to  8171 

update  this  element.  Must  be  nine  digits  and  a B174 

valid  PWC. 

Input  only  when  a change  transaction  is  used  to  3204 

update  this  element.  Must  be  a valid  RO. 


Input  only  when  a change  transaction  is  used  to  3194 

update  this  element.  Must  be  a valid  Object  Class. 


Input  only  when  a change  transaction  is  used  to  3323 
update  this  element.  Must  be  a valid  Performing  C509 
Organization.  C510 

Input  only  when  a change  transaction  is  used  to  B330 
update  this  element.  Must  be  five  positions.  If  B331 
the  first  position  is  0 or  1,  must  be  a Centerwide  C509 


Job  Code  and  validated  with  FS  and  Performing  Orga- 
nization defined  for  the  performance  data  being 
changed  or  with  updated  values  if  either  or  both 
are  changed  in  the  transaction. 


Input  only  when  a change  transaction  is  used  to  B340 

update  this  element.  A Primary  Job  Code  must  already  B341 
exist  for  the  performance  data  being  changed  or  be  B342 

input  as  a part  of  this  transaction.  Must  be  five  C510 

positions.  If  the  first  position  is  0 or  1,  must  be 
a Centerwide  Job  Code  and  validated  with  FS  and  Per- 
forming Organization  defined  for  the  performance  data 


being  changed  or  with  updated  values  if  either  or  both 
are  changed  in  the  transaction. 


Figure  2.7-7.  - Blanket  Purchase  Agreement  update  and  correction  input  and  edit  requirements. 
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Error 
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Input/Edit  requirements 

Error 

code 

Method  of 
Authority 

BP  A document 
or  other 
update 
document 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  MA  but  not 
97. 

B 1 11 
B115 

Program  Year 

Conditional 

BPA  document 
or  other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  PY.  Also 
must  be  validated  with  FS  defined  for  the  per- 
formance data  being  changed  or  with  updated 
values  if  either  or  both  are  changed  in  this  trans- 
action . 

B 1 2 1 
C5  08 

Fund  Source 

Conditional 

BPA  document 
or  other 
Update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  FS.  Also 
must  be  validated  with  PY  defined  for  the  per- 
formance data  being  changed  or  with  updated 
values  if  either  or  both  are  changed  in  the  trans- 
action. 

B 1 39 
C508 

Purchase 

P.eguest 

Number 

Yes 

BPA  document 
or  other 
update 
document 

Fatal 

Input  for  all  change  transactions.  Must  be  numeric. 

3300 

B301 

Purchase 

Fequest 

Number 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  only  when  a change  transaction  is  to  be  applied 
to  a suffix  other  than  the  base  suffix.  Must  be 
numeric. 

B311 

Contract/ 

Order 

Number 

Conditional 

BPA  document 
or  other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Positions  1 and  2 must  be  a 
valid  Contract/Order  prefix. 

B36“1 

Call  number 

Conditional 

BPA  document 
or  other 
update 
document 

None 

Input  only  when  a change  transaction  is  used  to  update 
this  element. 

None 

Commitment/ 

Obligation 

Dollars 

Conditional 

BPA  document 
or  other 
update 
document 

Fatal 

Input  as  a net  change  when  a change  transaction  is 
used  to  update  this  element.  Must  be  numeric  and 
not  equal  to  0. 

B651 

B652 

Figure  2.7-7.  - Blanket  Purchase  Agreement  update  and  correction  input  and  edit  requirements  (continued). 


Data 

Element 

Error 

Input/Edit  requirements 

element 

required 

Source 

Type  of 
Blanket 
Purchase 
Request 

Yes 

BPA  document 
or  user 
supplied 

Fatal* 

Must  be  input  for  all  change  transactions  as  either 
•Regular1  for  any  update  to  performance  data  recorded 
for  Regular  BPA  calls  or  'Tech  Services*  for  any  up- 
date to  perf ormance'data  recorded  for  BP A-Technical 
Services  calls. 

Extent  of 
Obligation 

Conditional 

BPA  document 
or  user 
supplied 

Fatal 

Input  only  when  the  Commitment/Dbligation  Dollars  are 
input.  Must  be  either  'partial1  if  the  change  is  to  a 
suffix  other  than  the  base  suffix  or  •complete*  if 
the  change  is  to  be  made  to.  the  base  suffix. 

For  changes 
only 

Yes 

User  supplied 

Fatal 

Transaction  modifier.  Input  as  either  ‘update*  if  the 
change  being  made  is  directed  by  documentation  or 
* correction*  if  the  change  being  made  is  because  of 
erroneous  initial  input. 

Figure  2.7-7.  — Blanket  Purchase  Agreement,  update  and  correction  input  and  edit  requirements  (concluded) 


Error 

code_ 

C430 

C437- 


C 42 1 


B062 


defined  to  change  existing  data,  an  error  message  is  to  be 
output  if  the  performance  data  record  designated  by  the  PR 
Number  and  Suffix  does  not  exist.  For  those  data  elements 
that  have  no  effect  on  the  funds  availability  process 
(Performing  Organization,  Primary  and  Secondary  Job  Codes, 
Contract/Order  Number,  and  Call  number) , the  data  elements 
can  be  updated  directly. 

Changes  to  the  dollars,  MA,  PY,  FS,  20,  PWC  (if  FS  is  4 
or  above) , and  Object  Class  (FS  3)  have  an  effect  on  the 
Fund  Control  accounts  and,  thus,  have  more  extensive 
processing  requirements.  Changes  to  the  dollar  amount  are 
controlled  by  the  extent  of  obligation  specified.  If  either 
partial  or  complete  is  specified,  the  obligation  field  is 
increased  or  decreased  depending  on  the  sign  of  the  dollar 
amount  entered.  If  an  increase  would  cause  the  obligation 
to  exceed  the  commitment,  a table  of  preestablished  limits 
must  be  checked  to  determine  whether  the  additional  funds 
can  be  obtained  automatically  from  the  funding  PWA  account. 
If  the  additional  funds  exceed  the  limits  established  in  the 
table,  processing  must  be  halted  and  an  error  message 
provided  to  the  user.  If  the  required  amount  is  less  than 
the  limit,  additional  funds  in  the  amount  of  that  difference 
must  be  obtained  from  the  funding  PWA  account  entry,  and  the 
entry  issues  and  the  commitment  must  be  increased.  An 
advisory  message  must  inform  the  user  of  the  amount  of  funds 
obtained  from  the  funding  PWA  account.  If  the  funding  PWA 
account  entry  balance  is  insufficient,  processing  ceases  and 
an  error  message  is  provided.  If  complete  is  specified  and 
the  obligation  is  reduced,  the  commitment  must  also  be 
reduced  by  the  amount  necessary  to  make  the  commitment  equal 
to  the  obligation.  The  funding  PWA  account  entry  issues 
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must  be  reduced  by  a like  amount  (increasing  the  balance) . 
Changes  to  any  of  the  other  data  elements  listed  result  in  a 
change  to  the  funding  PWA  account  entry.  As  a result,  the 
entire  commitment  amount  must  be  subtracted  from  the  issues 
of  the  original  funding  PWA  account  entry,  the  availability 
of  funds  in  the  new  funding  PWA  account  entry  checked,  the 
issues  of  the  new  funding  PWA  account  entry  increased,  and 
the  changed  data  element  updated  in  the  performance  data 
record.  To  satisfy  audit  trail  requirements,  the 
transaction  must  be  recorded  in  a transaction  history. 

Output  - Section  2.7.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
this  transaction. 

2.7. 1.3  GBL documents . A memorandum  copy  of  the  GBL 

(SF1103A)  is  used  by  JSC  to  record  the  commitment, 
obligation,  and  cost  for  the  commercial  transportation  of 
goods  as  required  by  JSC.  The  GBL  contains  the  accounting 
data  required,  the  estimated  dollar  changes,  the  description 
of  the  goods  shipped,  and  the  signature  of  the  authorising 
official. 

2.7. 1.3.1  Initial  recording:  The  information 
contained  on  the  GBL  received  in  the  Fund  Control  Unit  must 
be  recorded  as  a part  of  the  performance  data  maintained  in 
IFMS  and  requires  a funds  availability  check. 

Input  - Information  that  must  be  input  for  any  GBL  is 
obtained  from  the  GBL  or  is  user  supplied.  The  input  data 
elements  and  data  edits  required  are  shown  in  figure  2.7-8. 
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-8.  - Government 

Bill  of 

Input/Edit  requirements 


Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  GBL  transactions.  The  first  position 
must  be  alphabetic,  and  the  remaining  seven  positions 
must  be  numeric.  « 


Input  only  when  it  is  a supplemental  GBL. 

Input  for  all  GBL  transactions.  Must  be  nine  digits 
and  a valid  PWC. 


Input  for  all  GBL  transactions.  Must  be  a valid  RO. 


Input  for  all  GBL  transactions.  Must  be  a valid 
Object  Class. 

Input  for  all  GBL  transactions.  Must  be  a valid 
Performing  Organization. 


Input  if  it  is  provided  on  the  source  document. 

Must  be  five  positions.  If  the  first  position  is 
0 or  1,  must  be  a Centerwide  Job  Code  and  validated 
with  FS  and  Performing  Organization. 

Input  if  provided  on  the  source  document  and  a 
Primary  Job  Code  is  input.  If  the  first  position 
is  0 or  1,  must  be  a Centerwide  Job  Code  and  vali- 
dated with  FS  and  Performing  Organization. 


Input  for  all  GBL  transactions. 
MA  but  not  97. 


Must  be  a valid 


Input  for  all  GBL  transactions.  Must  be  a valid 
PY.  Also  validated  with  FS. 


Data 

element 

Element 

required 

Source 

Error 

txpe 

Input/Edit  requirements 

Erro: 

code 

Fund  Source 

Yes 

User  supplied 

Fatal 

Input  for 
FS.  Also 

all  GBL  transactions.  Must 
validated  with  PY. 

be  a valid 

B130 

B139 

C500 

Contract/ 

Order 

Number 

Generated 

System 

supplied 

None 

Generated 

for  all  GBL  transactions  as 

X98000. 

None 

Commitment 
Obligation, 
and  Cost 
Dollars 

Yes 

GBL 

Fatal 

Input  for 
not  equal 

all  GBL  transactions.  Must 
to  0. 

be  numeric  and 

B660 

B661 

B662 

Correction 

No 

None 

None 

Must  not  be  input  for  initial  GBL  transactions. 

None 

Figure  2.7-8.  - Government  Bill  of  Lading  initial  input  and  edit  requirements  (concluded) 


The  template  required  for  input  of  these  elements  is  shown 
in  figure  2.7-9. 

Processing  — The  initial  recording  of  a GBL  requires 
that  the  data  base  not  already  contain  a performance  data 
record  identified  by  the  input  GBL  number.  If  such  a record 
does  exist,  the  transaction  is  in  error. 

The  availability  of  funds  in  the  funding  PWA  account 
entry  must  be  established  for  the  GBL  dollar  amount.  The 

funding  PWA  account  entry  is  determined  by  MA , PY,  FS, 

funding  RO,  and  PWC  (if  it  is  FS  4 or  above)  or  funding 

Object  Class  for  current  year  FS  1,  2,  or  3 for  prior  years 

which  requires  only  MA , PY,  FS,  and  funding  RO.  Funding  RO 
and  funding  Object  Class  are  converted  as  required  from  the 
RO  and  Object  Class  input  to  the  transaction.  The  funding 
PWA  account  issues  must  be  increased  by  the  input  dollar 
amount  provided  the  balance  is  sufficient  to  fund  the  GBL. 

A performance  data  record  must  be  established  for  each 
GBL  accepted.  The  base  Suffix  must  be  automatically 
assigned  when  a suffix  is  not  input.  The  following  data 
elements  must  be  included: 

• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 

• Primary  and  Secondary  Job  Codes  (if  provided) 

• Method  of  Authority 

• Program  Year 

• Fund  Source 


V 

Si4  jr 


****IFMS  SEPTEMBER  30,  1974  AS  OF 
****TEMPLATE  NO.  K3  - GBL 

GBL  NO.  SUFFIX 

PWC  RESP  ORG OBJECT  CLASS 

PERF  ORG  PRIMARY  JOB  CODE  SECONDARY  JOB  CODE 

MA  PY FS 

COMMITMENT/OBLIGATION/COST  . $ , . ± 

CORRECTION 


Figure  2.7-9 


Government  Bill  of  Lading  template 


• Contract/Order  Number 

• Commitment  Dollars 

• Obligation  Dollars 

• Cost  Dollars 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 

QUiEUt  - Section  2.7.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 


2.7. 1.3.2  Correction:  After  the  initial  recording  of 
the  GBL , the  capability  to  correct  any  erroneous  input  must 
be  provided. 

Input  - The  GBL  number  and  Suffix  identify  the  unique 
data  element  set  to  which  the  correction  is  to  be  made.  If 
a change  is  applicable  to  the  base  Suffix,  only  the  GBL 
number  is  required  input,  and  the  base  Suffix  is  generated. 
If  the  change  is  applicable  to  any  suffix  other  than  the 
base  Suffix,  both  the  GBL  number  and  Suffix  are  required 
input.  Corrections  required  because  of  an  erroneous  GBL 
number  or  Suffix  must  be  corrected  by  a reversal  of  the 
original  transaction  having  the  erroneous  data  and  by  the 
input  of  a complete  transaction  (all  data  elements)  with  the 
correct  data.  Figure  2.7-10  shows  the  possible  data  element 
corrections  and  data  edits  required.  The  GBL  template 
required  for  input  of  these  data  elements  is  illustrated  in 
figure  2.7-9. 


A \ 
T"'  “s' 


£ i 

V.  y 


Data 

element 

Element 

required 

Source 

Error 

Input/Edit  requirements 

Error 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Government 
Bill  of 
Lading 
number 

Yes 

GBL 

Fatal 

Input  for  all  GBL  change  transactions.  The  first 
position  must  be  alphabetic,  and  the  remaining  seven 
positions  must  be  numeric. 

B420 
B 42 1 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  when  a GBL  change  transaction  is  to  be  applied 
to  a suffix  other  than  the  base  suffix.  Must  be 
numeric. 

B311 

Primary  Work 
Code 

Conditional 

GBL  or 
other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  nine  digits  and  a valid 
PWC. 

B 17  1 
Bl  74 

Responsible 

Organization 

Conditional 

GBL  or 
other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  RO. 

B 20  1 

Object  Class 

Conditional 

GBL  or 
other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  Object  Class. 

B 191 

Performing 

Organization 

Conditional 

GBL  or 
other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  Performing 
Organization. 

B321 
C509 
C5 1 0 

Primary  Job 
Code 

Conditional 

GBL  or 
other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  five  positions.  If  the 
first  position  is  0 or  1 , must  be  a Centerwide  Job 
Code  and  validated  with  FS  and  Performing  Organization 

B330 
B33  1 
C509 

defined  for  the  performance  data  being  changed  or  with 
updated  values  if  either  or  both  are  changed  in  the 
transaction. 


Figure  .2.7-10.  - Government  Bill  of  Lading  update  and  correction  input  and  edit  requirements. 


Data 

element 

Element 

required 

Source 

Error 

Error 

code 

Secondary 
Job  Code 

Conditional 

G3L  or 
other 
update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  A Primary  Job  Code  must  already 
exist  for  the  performance  data  being  changed  or  be 
input  as  a part  of  this  transaction.  Bust  be  five 
positions.  If  the  first  position  is  0 or  1,  must  be 
a Centerwide  Job  Code  and  validated  with  FS  and  Per- 
forming Organization  defined  for  the  performance  data 
being  changed  or  with  updated  values  if  either  or 
both  are  changed  in  the  transaction. 

B340 

B341 

B342 

C510 

Method  of 
Authority 

Conditional 

User  supplied 
or  update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Bust  be  a valid  HA  but  not  97. 

Bill 

B 1 1 5 

Program  Year 

Conditional 

User  supplied 
or  update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Bust  be  a valid  PY.  Also  must  be 
validated  with  FS  defined  for  the  performance  data 
being  changed  or  with  updated  values  if  either 
or  both  are  changed  in  this  transaction. 

5121 

B 1 22 
C508 

Fund  Source 

Conditional 

User  supplied 
or  update 
document 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  a valid  FS.  Also  must 
be  validated  with  PY  defined  for  the  performance 
data  being  changed  or  with  updated  values  if  ei.ther 
or  both  are  changed  in  the  transaction. 

B 1 39 
C508 
C509 
C510 

Commitment, 
Obligation, 
and  Cost 
Dollars 

Conditional 

GBL  or 

other 

document 

Fatal 

Input  as  a net  change  when  a change  transaction  is 
used  to  update  this  element.  Must  be  numeric  and 
not  ogual  to  0. 

B66 1 
B662 

Correction 

Yes 

User  supplied 

None 

Must  be  input. 

None 

Figure  2.7-10.  -.Government  Bill  of  Lading  update  and  correction  input  and  edit  requirements  (concluded). 


Processing  - Processing  requirements  for  the  correction 
transaction  vary  according  to  the  data  elements  being 
changed.  As  the  transaction  is  defined  to  change  existing 
data,  an  error  message  is  to  be  output  if  the  designated 
performance  data  record  does  not  exist. 


Changes  to  the  Performing  Organization,  Primary  Job 
Code,  and  secondary  Job  Code  can  be  updated  directly. 
Changes  to  the  dollar  amount,  MA,  PY , FS,  RO , PWC  (if  it  is 
FS  4 or  above),  and  Object  Class  (FS  1,  2,  or  3)  have  an 
effect  on  the  Fund  Control  accounts  and,  thus,  have  more 
extensive  processing  requirements.  A decrease  in  the  dollar 
amount  requires  that  the  commitment,  obligation,  and  cost 
fields  of  the  specified  performance  data  record  be  reduced 
by  the  input  dollar  amount.  The  funding  PWA  account  entry 
issues  must  be  reduced  by  the  same  amount  (increasing  the 
balance) . A dollar  increase  requires  that  a funds 

availability  check  be  made  for  the  amount  of  the  increase 
and  that  the  funding  PWA  account  entry  issues  and  the 
specified  performance  data  record  commitment,  obligation, 
and  cost  fields  be  increased  provided  the  funding  PWA 
account  entry  balance  is  sufficient  to  fund  the  additional 
dollars.  Changes  to  any  of  the  other  data  elements  listed 
above  result  in  a change  to  the  funding  PWA  account  entry. 
As  a result,  the  entire  commitment  amount  must  be  subtracted 
from  the'  issues  of  the  original  funding  PWA  account  entry, 
the  availability  of  funds  in  the  new  funding  PWA  account 
entry  checked,  the  issues  of  the  new  funding  PWA  account 
entry  increased,  and  the  changed  data  element  updated  xn  the 
specified  performance  data  record.  To  satisfy  audit  trail 
requirements,  the  transaction  must  be  recorded  xn  a 
transaction  history. 


must 


Out gut  - Section  2.7.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 

2.7.2  Output  Message  Requirements 

Figures  2.7-11  through  2.7-15  contain  a list  of  output 
message  requirements.  Figure  2.7-16  contains  a correlation 
of  output  messages  by  the  Obligation  process  transaction. 

2.7.3  Inquiry  Requirements 

Figure  2.7-17  contains  a list  of  inquiry  data  elements 
and  response  data  elements  required  for  the  Obligation 
process . 

2.7.4  Report  Requirements 

The  report  requirements  for  the  Obligation  process  are 
described  in  section  2.19.6.  These  reports  are  the 
following : 

• Unobligated  Commitments 

• open  Commercial  Order  Status 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  Obligation  Process  Section  described 
in  section  2.19.7. 


2.7-36 


Message 


Code 

****  CONTRACTING  AND  MISCELLANEOUS  OBLIGATION  TRANSACTION  - INITIAL 

****  CONTRACTING  AND  MISCELLANEOUS  OBLIGATION  TRANSACTION  - CORRECTION 

****  BP A CALL  TRANSACTION  - INITIAL 

****  BP A CALL  TRANSACTION  - UPDATE 

****  BP A CALL  TRANSACTION  - CORRECTION 

****  GBL  TRANSACTION  - INITIAL 

****  GBL  TRANSACTION  “ CORRECTION 

B062  BOTH  'UPDATE*  AND  'CORRECTION'  MUST  NOT  BE  SPECIFIED 

B 420  EXTENT  OF  OBLIGATION  NOT  SPECIFIED 

B 4 21  MULTIPLE  EXTENT  OF  OBLIGATIONS  SPECIFIED 

C 430  TYPE  OF  BP A NOT  SPECIFIED 

C431  MULTIPLE  TYPES  OF  BP A SPECIFIED 

Figure  2.7-11.  - Obligation  transaction-begun  messages. 


Code  Message 

A 000  TRANSACTION  COMPLETE 

Figure  2.7-12.  - Obligation  transaction-complete  messages. 


2. 7-37 


Co^e 


Message 


B100  'AS  OF'  DATE  INVALID 

B 1 0 1 'AS  OF'  DATE  MOST  BE  PRIOR  TO  SYSTEM  DATE / / 

B 1 1 0 MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 1 5 MA  MUST  NOT  BE  97 

B120  PY  NOT  ENTERED 

B121  PY  INVALID 

B1 30  FS  NOT  ENTERED 

B1 39  FS  INVALID 

B170  PNC  NOT  ENTERED 

P171  PWC  INVALID 

B 1 74  PWC  MUST  BE  9 DIGITS 

B190  OBJECT  CLASS  NOT  ENTERED 

B191  OBJECT  CLASS  INVALID 

B1 94  OBJECT  CLASS  INVALID 

B200  RESPONSIBLE  ORGANIZATION  NOT  ENTERED 

B201  RESPONSIBLE  ORGANIZATION  INVALID 

B204  RESPONSIBLE  ORGANIZATION  INVALID 

B300  PURCHASE  REQUEST  NUMBER  NOT  ENTERED 

B301  PURCHASE  REQUEST  NUMBER  INVALID 

B3 1 1 SUFFIX  INVALID 

B312  SUFFIX  RUST  BE  BLANK 

B320  PERFORMING  ORGANIZATION  NOT  ENTERED 

B321  PERFORMING  ORGANIZATION  INVALID 

B323  PERFORMING  ORGANIZATION  INVALID 

B330  PRIMARY  JOB  CODE  INVALID 

B331  PRIMARY  JOB  CODE  MUST  BE  CENTERWIDE  JOB  CODE 

B340  SECONDARY  JOB  CODE  INVALID 

B341  SECONDARY  JOB  CODE  MUST  BE  BLANK 

B342  SECONDARY  JOB  CODE  MUST  BE  CENTERWIDE  JOB  CODE 

B360  CONTRACT/ORDER  NUMBER  NOT  ENTERED 

B361  CONTRACT/ORDER  NUMBER  INVALID 

B370  CONTRACT  AMENDMENT  NUMBER  INVALID 

B371  CONTRACT  AMENDMENT  NUMBER  MUST  BE  NUMERIC 


Figure  2.7-13.  - Obligation  data  element  edit  error  messages. 


2. 7-38 


Code  Message 

B380  CONTRACT  SCHEDULE  NUMBER  INVALID 

B390  DOCUMENT  TYPE  CODE  INVALID 

B400  CONTRACTOR  NAME  CODE  INVALID 
6410  BP  A CALL  NUMBER  NOT  ENTERED 
B420  GBL  NUMBER  NOT  ENTERED 

B421  GBL  NUMBER  INVALID 

B430  RUNNING  INDICATOR  MOST  NOT  BE  ENTERED 

F620  OBLIGATION  $ NOT  ENTERED 

B621  OBLIGATION  S INVALID 

B6 22  OBLIGATION  S MUST  NOT  BE  ZERO 

B650  C/O  * NOT  ENTERED 

B651  C/O  S INVALID 

B652  C/O  f MUST  NOT  BE  ZERO 

B660  C/O/C  $ NOT  ENTERED 

B661  C/O/C  $ INVALID 

B662  C/O/C  * MUST  NOT  BE  ZERO 

C500  PY,  FS  COMBINATION  INVALID 

C506  FS,  PERF  ORG,  PRIMARY  JOB  CODE  COMBINATION  INVALID 
C507  FS , PERF  ORG,  SECONDARY  JOB  CODE  COMBINATION  INVALID 
C508  PY  , FS  COMBINATION  INVALID 

C509  FS  , PERF  ORG  , PRIMARY  JOB  CODE  COMBINATION  INVALID 

c510  FS  f PERF  ORG  , SECONDARY  JOB  CODE  COMBINATION  INVALID 


Figure  2.7-13.  - Obligation  data  element  edit  error  messages  (concluded). 


2.7-39 


> 


I 

Code  Message 

| A210  SUFFIX  GENERATED  AS 


r\ 


Figure  2.7-14.  - Obligation  processing  advisory  messages. 


2.7-40 


sag  > 


■ 

■S,.T  X 


Code  Message 

D 1 40  PW A RECORD  NOT  FOUND 

MA PY FS RO PWC  

OBJECT  CLASS  CARRIER  ID  SUB  ID 

D142  PW  A ISSUES  INSUFFICIENT 

MA PY FS RO PWC  

OBJECT  CLASS  CARRIER  ID  SUB  ID 

ISSUES  UPDATE  $_* , , . 

D 1 43  PWA  BALANCE  INSUFFICIENT  TO  INCREASE  ISSUES 

MA PY  FS RO PWC  

OBJECT  CLASS  CARRIER  ID  SUB  ID 

BALANCE  $_, , , UPDATE  $_, , , 

D 1 80  PERFORMANCE  DATA  RECORD  NOT  FOUND 

PURCHASE  REQUEST  NO.  SUFFIX  

D 1 8 5 COST  $ INSUFFICIENT  TO  REDUCE  OBLIGATION  $ 

PURCHASE  REQUEST  NO.  SUFFIX  

COST  $_, , , . OBLIGATION  , , 

UPDATE  , , . - 

D 1 86  PERFORMANCE  DATA  RECORD  CLOSED 

PURCHASE  REQUEST  NO.  SUFFIX  

D 1 87  PERFORMANCE  DATA  RECORD  NOT  FOUND 

GBL  NO.  SUFFIX 

D 1 88  PERFORMANCE  DATA  RECORD  ALREADY  EXISTS 

GBL  NO.  SUFFIX 

D 1 89  C/O/C  $ INSUFFICIENT 

GBL  NO.  SUFFIX 

C/O/C  , , . UPDATE  , , ._ 

D 1 90  INFORMATION  RECORD  NOT  FOUND 

PURCHASE  REQUEST  NO.  i 

Figure  2.7-15.  - Obligation  processing  error  messages. 


2.7-41 


. .. . 


Zfl- 


Transaction 


Message  AABBBBBB 
0 2 0 1 1 1 1 1 

0 1 6 0 0 1 1 1 

0 0 2 0 1 0 1 5 


bbbbbbbbb 
111111111 
2 2 2337779 

0 1 2 0 9 0 1 4 0 


bbbbbbbbbb 
1 122233333 
9900000112 
1401401120 


Miscelianepus_Obligatidn 

Initial 

Correction 


XX  XX 

X X X 


XXX 

XXX 


B t _P u rch as e_ Agreement 

Initial 

Update  and  Correction 

Government  Bill  of  Lading 

Initial 

Correction 


X X X X X X X X X 

X XXX  XX  X 


X X X X X X 

X XX 


XX  XX 

r.  X x x x X 


X 


X 

X 


X 


X X X X X X X 

X X X X X 


X X X X X X 

X X X 


to 


Message 


Transaction 

r2£trgilli-ligi  an^  MisceIlaneous_Obligai:ign 

Initial 

Correction 

0 lanket_P u rch ase_ Agr ee me n t 

Initial  ~ 

Update  and  Correction 


B B B B B 8 B B 
33  3 3 3333 
22334446 
13  0 10  12  0 


X 


X X X X X X X 

X X X X X x 


bbbbbbbbb 

3 3 3334444 

6 77890  1 22 

10  1 000001 


X X X X X X 

X X X X X X 


x X 

X 


BBBBBBBBBB 
4666666666 
3222555666 
00  1 2012012 


XXX 
X XX 


XXX 
X X 


Gnygrnment  Bill  of  Lading 

Initial 

Correction 


X X X X X X 

X X X X X X 


X X 
X X 


XXX 
X X 


Figure  2.7-16.  - Obligation  messages  by  transaction 


x x 


Transaction 


A. 


Message  C C C 
4 4 4 

2 2 3 

0 1 0 

Con  tract  ing_and_Miscel  la  neou.s_Obligat  ion 


Initial  x x 

Correction  X 

Blank et_Purchase_Agreeaent 

Initial  XXX 

Update  and  Correction  X X 


Co vernroen t _Bill_of _L ad ing 

Initial 

Correction 


CCCCCCCDDDDDDDDDD 

4555555  1 1111  1 1111 

3 0000014448888889 

10678900  2 3056  7 890 


X X X X X X 

X X X X 


X X X X XXXXXX  X 

X XXXXXXX 


XXX  XX  X 

XXXXXX  X X 


Figure  2.7-16.  - obligation  messages  by  transaction  (concluded) 


Inquiry  description 


IIBE 


Input  data  elements 


Timing 


Purchase  Bequest  status 


GRL  status 


GPL  highest  suffix 
assigned 

Purchase  Request  status 
(all  suffixes) 


Item 


Purchase  Request  Number  Immediate 
Suffix  (when  other  than 
base  Suffix  status 
required) 


Purchase  Reguest  Number 
Suffix 

Method  of  Authority 
Progarm  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 

Responsiole  Organization 

Object  Class 

Performing  Organization 

Primary  Job  Code 

Secondary  Job  Code 

Contract/Order  Number 

Contract  Schedule  Number 

Amendment  Number 

Contractor  name  code 

Commitment 

coligation 

Cost 

Disbursement 


Item 


GB1,  number 
Suffix  (wnen  other 
than  case  Suffix 
status  required) 


Immediate  GBL  number 

Suffix 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  code  (nine  digits) 

Responsible  organization 

Object  class 

Performing  Organization 

Primary  Job  code 

Secondary  Job  Code 

Contract/Order  Number 

Commitment 

Obligation 

cost 

Disbursement 


Item 

GPL  number 

List 

Purchase  Request 

Number 

Immediate  GBL  number 

Highest  suffix  assigned 

Immediate  Purchase  Reguest  Number 

Suffix 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  organization 
Object  Class 
Performing  Organization 
Primary  Job  Code 
Secondary  Job  Code 
Contract/Order  Number 
. Contract  Schedule  Number 
Amendment  Number 
Contractor  name  code 
Commitment 
Obligation 
Cost 

Disbursement 


Figure  2.7-17.  - Obligation  inquiry  requirements. 


2.8  COST  ACCRUAL  PROCESS 


Cost,  accruals  are  made  on  a monthly  basis.  A cost  must 
be  recorded  at  the  time  of  the  disbursement.  In  addition, 
the  cost  must  be  recorded  to  reflect  the  performance  of 
services  and  the  consumption  of  materials  in  lieu  of  the 
disbursement.  This  recognition  of  cost  for  services  and 
materials  in  the  absence  of  a disbursement  is  referred  to  as 
cost  accrual.  The  following  sections  will  describe  how  the 
different  types  of  cost  accruals  take  place. 

2.8.1  Update  Requirements 

2.8. 1.1  Contract data creation.  The  IFMS  concept  of 

contract  data  with  associated  performance  data  will  be 
referred  to  within  this  process.  * Information  in  the 
contract  data  which  is  applicable  to  the  cost  accrual 
process  is  as  follows.  The  accrual  type  identifies  the 
method  of  accrual  for  contracts,  i.e. , automatic  accrual. 
Form  100  accrual,  or  manual  accrual.  The  contract  status 
identifier  shows  whether  a contract  is  vin  an  active  or 
inactive  status.  The  cost  accountant  responsible  code 
identifies  the  cost  accountant  responsible  for  a Form  100  or 
manual  accrual.  In  addition,  the  contract  level  dollar 
amounts  required  in  the  process  are  the  obligation,  cost, 
disbursement,  obligation  for  nonexcluded  object  classes,  and 
cost  for  nonexcluded  object  classes. 

Contract  data  will  be  created  automatically  in  the 
Obligation  process  for  grants  and  contracts.  T-orders, 
however,  will  not  have  contract  data  automatically 
generated.  A requirement  exists  to  create  contract  data 
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online  for  T-orders  by  the  Cost  Accounting  Section  when  use 
is  desired  of  the  contract  data  facility  in  accruing  costs. 
Existing  contract  data  will  need  to  be  updated  and 
corrected.  In  addition,  contract  data  created  erroneously 
will  need  to  be  deleted. 

2. 8. 1.1.1  Initial  establishment 

Input  - The  data  elements  used  in  establishing  contract 
data  are  described  in  figure  2.8-1.  The  template  required 
for  input  of  these  data  elements  is  shown  in  figure  2.8-2. 

Processing  - In  order  to  establish  contract  data, 
certain  conditions  are  necessary.  First,  duplicate  contract 
information  must  not  already  exist.  Second,  performance 
data  must  exist  having  the  same  T-order  number  as  on  the 
contract  data.  Once  the  above  requirements  have  been  met, 
certain  amount  fields  are  updated  automatically  as  part  of 
the  contract  data.  Obligation,  cost,  and  disbursement  data 
will  be  generated  for  the  total  of  the  corresponding  amounts 
for  the  performance  data.  Likewise,  the  obligation  and  the 
cost  amounts  for  nonexcluded  object  classes  (those  which  are 
not  2200,  4000,  5000  or  6001)  will  be  generated 
automatically  from  PE's  with  nonexcluded  object  classes. 
Certain  descriptive  information  for  the  contract  data  will 
be  generated  automatically.  This  includes  the  amendment 
number,  contract  type,  and  contractor  name  code.  An 
amendment  number  will  be  generated  by  determining  the 
highest  amendment  number  on  the  entire  set  of  PR's 
associated  with  a contract.  The  contract  type  can  be 
determined  and  generated  by  converting  any  one  of  the 
document  type  codes  on  the  PR's  to  a commercial  or 
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Figure  2.8-1 


Error 
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I nput^Edit_ requirements 


Error 

code 


Fatal  Date  providing  for  the  backdating  of  transactions.  3100 

input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Fatal  Must  be  input  and  have  a prefix  of  T fcr  creation  B360 

or  deletion.  dust  be  input  and  have  a valid  prefix  B361 

for  an  update  and  correction. 

Fatal  Must  be  input  for  creation  and  be  a valid  accrual  B440 

type  which  reflects  an  automatic  accrual.  Form  100  B 

accrual,  or  manual  accrual.  If  input  for  an  update  B442 

it = walia  arrrnal  tVDe  which 


and  correction,  must  be  a valid  accrual  type  which 
reflects  automatic  accrual.  Form  100  accrual,  or 
manual  accrual.  Not  input  for  deletion. 


Fatal  Must  be  input  for  creation,  and  must  be  numeric.  B450 

If  input  for  an  update  and  correction,  must  be  nu-  B451 

meric.  Dot  input  for  deletion. 

Fatal  Not  input  for  creation  or  deletion.  If  input  for  an  B460 

update  and  correction,  the  contract  status  must  show  B461 

a valid  active  or  inactive  indicator.  b463 

Fatal  Transaction  modifier.  Input  as  either  • update*  if  B470 

the  change  being  made  is  directed  by  documentation 
or  1 correction 1 if  the  change  being  made  is  because 
of  erroneous  initial  input. 

Fatal  Input  only  when  it  is  desired  to  delete  contract  B470 

data  previously  input  online. 


- contract  data  input  and  edit  requirements. 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  L3  - CONTRACT  RECORD 

CONTRACT/ORDER  NO.  

TYPE  OF  ACCRUAL:  AUTOMATIC  _ FORM  100 

RESPONSIBLE  COST  ACCOUNTANT 
CONTRACT  STATUS:  ACTIVE  _ INACTIVE  _ 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION 

DELETION 


MANUAL 


Figure  2.8-2.  - Contract  Data  template 


government  classification.  The  contractor  name  code  can  be 
generated  by  using  the  contractor  name  code  on  any  of  the 
PR  * s associated  with  a contract.  Following  the  creation  of 
contract  data,  a transaction  is  recorded  in  a transaction 
history. 

i 

22£EJit  ~ Section  2.8.2  describes  the  standard  online  j 

responses  and  error  messages  required  in  the  processing  of  j 

the  transaction.  j 

* \ 

2. 8. 1.1. 2 Update  and  correction:  An  update  and  j 

correction  may  be  made  not  only  to  contract  data  created  for  j 

T-orders  but  to  all  existing  contract  data  created  i 

automatically  at  the  obligation  stage.  i 

■ J 

In^ut  - The  data  elements  used  in  correcting  and 
updating  existing  contract  data  are  described  in  figure  2.8- 
1.  The  template  required  for  input  of  these  data  elements 
is  shown  in  figure  2.8-2. 

_ Per  an  update  or  correction  to  occur,  the 
following  must  be  true.  Contract  data  for  the  -j 

Contract/Order  Number  input  must  already  exist.  Once  this  \ 

has  been  verified,  the  update  or  correction  can  proceed. 

Input  data  will  replace  or  overlay  existing  data.  1 

Processing  will  be  the  same  as  described  in  section  I 

2.8. 1.1. 1.  . | 


OuifiSi  - Section  2.8.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 


2. 8. 1.1. 3 Deletion 


Input  - The  data  elements  used  in  correcting  and 
updating  existing  contract  data  are  described  in  figure  2.8- 
1.  The  template  required  for  input  of  these  data  elements 
is  shown  in  figure  2.8-2. 

Processing  - For  a deletion  to  occur,  the  following 
must  be  true.  Contract  data  for  T-order  input  must  already 
exist.  Once  this  has  been  verified,  the  contract  data  will 
be  deleted.  A transaction  will  be  recorded  in  a transaction 
history. 

Output  - Section  2.8.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  transaction. 

2.8.1. 2 Automatic accrual . This  type  of  accrual  is 

performed  with  no  direct  input  of  an  accrual  amount  but  is 
automatically  applied  by  means  of  a formula.  Processing 
will  take  place  in  a batch  mode  once  a month.  The  automatic 
cost  accrual  must  be  applied  to  each  contract  or  order  at 
the  contract  level  if  contract  data  exists  for  the  contract 
or  order  or  at  the  PR  level  if  no  contract  data  exists.  In 
both  kinds  of  accruals,  the  following  expiration  formula 
will  be  used:  percentage  of  completion  = days 
elasped/contract  life  in  days.  The  automatic  accrual 
process  will  obtain  a contract's  start  and  end  date  from  the 
Procurement  System  interface  when  these  dates  are  available. 
If  these  dates  are  not  available  or  in  error,  a life  of  8 
months  will  be  used. 


2.8, 1.2.1  Contract  level  accrual:  This  type  of 
accrual  will  have  calculations  made  at  the  contract  level 
and  costs  applied  to  individual  PR's.  This  particular  type 
of  accrual  occurs  on  a monthly  basis. 

Input  - Data  elements  and  edit  requirements  are  shown 
in  figure  2.8-3.  If  the  start  date  and  end  date  of  a 
contract  are  not  available  from  the  Procurement  System,  a 
life  of  8 months  will  be  used  the  first  time  a contract  is 
accrued.  Subsequently,  the  number  of  months  remaining  must 
be  used,  providing  the  start  date  and  end  date  do  not  become 
available.  This  number  will  be  stored  and  decremented 
(ultimately  to  0)  for  each  month's  accrual. 

Processing  - This  particular  process  specifies  that 
contract  data  be  examined  to  determine  whether  a contract  is 
(to  be  accrued  automatically.  If  a contract  is  to  be  accrued 
automatically,  the  expiration  formula  will  determine  the 
percentage  of  completion.  This  percentage  of  completion 
will  be  multiplied  by  the  contract  total  obligation  amount 
for  nonexcluded  object  classes.  The  result  will  be  the 
computed  accrued  cost,  which  will  then  be  compared  to  the 
contract  cost  amount  for  nonexcluded  object  classes.  If  the 
computed  accrued  cost  is  less  than  or  equal  to  the  contract 
cost  amount  for  nonexcluded  object  classes,  no  accrual  is  to 
be  made,  and  processing  will  continue.  If  the  computed 
accrued  cost  is  greater  then  the  contract  cost  amount  for 
nonexcluded  object  classes,  the  difference  between  the 
computed  accrued  cost  and  the  contract  cost  amount  for 
nonexcluded  object  classes  will  be  determined.  The 
difference  between  these  amounts  is  then  applied  to  the 
oldest  PR  (which  has  a cost  amount  less  than  the  obligation 
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Figure  2.8-3*  - Automatic  Accrual  input  and  edit  requirements. 


amount)  for  that  contract  and  then  so  on  to  the  next  oldest 
PE  until  the  cost  has  been  distributed.  Any  PR's  with 
excluded  object  classes  (2200,  4000,  5000,  or  6001)  will  be 
bypassed.  Contract  data  must  be  updated  for  the  cost  amount 
of  nonexcluded  object  classes  and  the  performance  cost 
amount.  The  transaction  must  be  recorded  in  a transaction 
history . 

Output  - No  errors  will  be  shown  for  this  process,  but 
a report  showing  the  results  of  the  processing  will  be 
described  in  section  2.8.4. 

2.8. 1.2.2  Purchase  request  level  accrual:  This  type 
of  accrual  will  be  made  for  performance  data  that  has  the 
following  characteristics:  reflects  a contract  prefix  of 
T,  exists  without  having  contract  data  associated  with  it, 
and  has  a nonexcluded  object  class.  Costs  will  be  applied 
directly  to  the  performance  data. 

Input  - Data  elements  and  edit  requirements  are  shown 
in  figure  2.8-3.  If  the  start  date  and  end  date  of  a 
contract  are  not  available  from  the  Procurement  System,  a 
life  of  8 months  will  be  assumed  the  first  time  a-  PR  is 
accrued.  'Subsequently,  the  number  of  months  remaining  must 
be  used.  This  number  will  be  stored  and  decremented 
(ultimately  to  0)  for  each  month's  accrual. 

Processing  - The  performance  data  to  be  accessed  will 
make  use  of  the  expiration  formula  described  in  section 
2.8. 1.2  to  determine  the  percentage  of  completion.  The 
percentage  of  completion  will  be  multiplied  by  the  purchase 
request  obligation  amount.  The  result  of  this  will  be  the 


computed  accrued  cost,  which  will  then  be  compared  to  the 
purchase  request  cost  amount.  If  the  computed  accrued  cost 
is  less  than  or  equal  to  the  purchase  request  cost  amount, 
no  accrual  is  to  be  made,  and  processing  will  continue.  If 
the  computed  accrued  cost  is  greater  than  the  purchase 
request  cost  amount,  the  computed  accrued  cost  will  replace 
the  purchase  request  cost  amount  for  the  performance  data. 
The  transaction  will  be  recorded  in  a transaction  history. 

Output  - No  errors  will  be  shown  for  this  process,  but 
a report  showing  the  results  of  the  processing  will  be 
described  in  section  2.8.4. 

2. 8. 1.3  Form 1 00 and manual accrual.  For  certain 

contracts,  contractors  are  required  to  submit  on  a monthly 
basis  to  budget  analysts  Form  533  which  gives  monthly 
estimated  costs.  From  Form  533,  budget  analysts  will 
prepare,  on  a Form  100,  contract  costs  at  the  desired  level 
of  accrual.  Another  type  of  accrual  performed  on  a monthly 
basis  is  a manual  accrual.  This  accrual  is  performed  for 
contracts  which  have  no  Form  100  submitted  by  budget 
analysts.  Because  these  contracts  reflect  a large 
obligation  amount,  the  Cost  Accounting  Section  will  cost 
them  in  a manner  similar  to  the  costing  of  Form  100 
contracts.  The  sources  for  determining  costs  for  this 
accrual  are  from  Receiving  and  Inspection  reports  contained 
in  the  contracts  file  in  Commercial  Accounts,  unpaid 
invoices  in  the  contracts  file,  and  support  level  office 
memos  sent  by  organizations  to  the  Cost  Accounting  Section. 
Both  the  Form  100  accrual  and  the  manual  accrual  can  be 
costed  at.  different  levels.  The  highest  level  of  accrual  is 
the  contract  number.  Cumulative  estimated  costs  can  be 


reported  solely  at  this  level.  A subordinate  level  to  the 
contract  number  consists  of  the  following  data  elements: 

• Contract  Schedule  Number 

• Primary  Work  Code 

• Fund  Source 

• Program  Year 

• Method  of  Authority 

• Responsible  Organization 

• Purchase  Reguest  Number 

• Purchase  Request  Suffix  Number 

This  subordinate  level  may  have  one,  several,  or  all  of  the 
above  data  elements  reported  along  with  the  contract  number, 
the  highest  level  data  element,  which  is  always  included  in 
the  Form  100  accrual  or  the  manual  accrual. 

Input  - Data  elements  and  edit  requirements  for  the 
Form  100  accrual  or  the  manual  accrual  are  shown  in  figure 
2.8-4.  Figure  2.8-5  shows  the  template  reguired  for  input 
of  these  data  elements  for  the  Form  100  accrual  or  the 
manual  accrual. 

Processing  - In  order  for  the  Form  100  accrual  or  the 
manual  accrual  to  take  place,  contract  data  for  the  given 
input  must  exist.  Otherwise,  processing  will  cease.  The 
accrual  type  or  the  contract  data  must  be  the  Form  100 
accrual  or  the  manual  accrual.  The  cumulative  accrued  cost 
input  must  not  exceed  the  obligation  amount  or  be  less  than 
the  disbursement  amount  contained  on  the  contract  data  or 
processing  will  cease.  The  apportionment  of  cumulative 
accrued  cost  will  begin  by  determining  whether  the  level  of 
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Figure  2.8-4.  - Form  100  and  Manual  Accrual  input  and  edit  requirements. 
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****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

****TEHPLATE  uO.  LI  - COST  ACCRUAL 

CONTRACT/ORDER  NO.  SCHEDULE  NO.  _ 

PWC  HA  __  PY  __  FS  __  RO 

PR  NO.  SUFFIX  

TYPE  OF  ACCRUAL:  FORH  100  _ MANUAL  _ 

CORRECTION  _ 


ACCRUAL  $ 


Figure  2.8-5.  - Cost  Accrual  template. 


input  for  the  Form  100  accrual  or  the  manual  accrual  exists. 
If  it  does  not,  processing  will  cease.  Next,  the 
apportionment  of  cumulative  accrued  cost  will  take  place  by 
computing  the  total  cost  amount  for  PR's  within  the  level  of 
input.  This  amount  will  be  subtracted  from  the  cumulative 
accrued  cost  input  which  results  in  the  accrued  change 
amount.  If  the  accrued  change  amount  is  positive,  the 
oldest  PR  in  which  the  obligation  exceeds  the  cost  within 
the  level  of  input  specified  will  be  selected.  The  cost 
will  be  increased  to  but  not  exceeding  the  obligation  amount 
for  a PR.  The  next  oldest  PR  in  which  the  obligation 
exceeds  the  cost  will  be  selected  if  additional  cost  is 
necessary.  If  the  cost  exceeds  the  obligation  while 
processing  a PR  within  a level,  cost  will  be  increased  to 
the  obligation  amount  on  that  PR.  The  remainder  of  the  cost 
will  be  displayed  as  cost  over  obligation  on  the  terminal  at 
the  level  Of  input.  If  the  accrued  change  amount  is 
negative,  the  youngest  PR  in  which  the  disbursement  is  less 
than  the  cost  will  be  selected.  The  cost  will  be  decreased 
to  but  not  below  the  disbursement  amount  for  that  PR.  The 
next  youngest  PR  in  which  the  disbursement  is  less  than  the 
cost  will  be  selected  if  additional  cost  needs  to  be 
reduced.  After  applying  the  accrued  change  amount  to  PR's 
within  a level,  it  is  necessary  to  adjust  the  performance 
cost  amount  on  the  contract  data  for  the  change  in  cost. 
This  insures  that  the  cost  amounts  for  the  PR's  on  a 
contract  total  the  contract  cost  amount.  The  cost  amount 
for  nonexcluded  object  classes  on  the  contract  data  will  be 
updated  for  the  Form  100  accrual  or  the  manual  accrual. 
This  total  will  be  maintained  in  order  to  allow  an  accrual 
type  for  the  Form  100  accrual  or  the  manual  accrual  to  be 
changed  at  any  time  to  an  automatic  accrual  and  the  contract 


costed  at  the  contract  level, 
recorded  in  a transaction  history. 


The  transaction  will  be 


” Section  2.8.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  processing  of 
the  Form  100  accrual  or  the  manual  accrual. 

2.8.2  Output  Message  Requirements 

Figures  2.8-6  through  2.8-9  contain  a list  of  output 
message  requirements.  Figure  2.8-10  contains  a correlation 
of  output  messages  by  the  Cost  Accrual  process. 

2.8.3  Inquiry  Requirements 

Figure  2.8-11  contains  a list  of  inquiry  input  data 
elements  required  for  the  Cost  Accrual  process. 

2.8.4  Report  Requirements 

The  Cost  Accrual  process  report  requirements  can  be 
found  in  section  2.19.3  and  section  2.19.7. 


Code 


Message 


****  COST  ACCRUAL  CONTRACT  TRANSACTION  - INITIAL  ESTABLISHMENT 

****  COST  ACCRUAL  CONTRACT  TRANSACTION  - UPDATE  AND  CORRECTION 

****  COST  ACCRUAL  CONTRACT  TRANSACTION  - DELETION 

****  AUTOMATIC  COST  ACCRUAL  TRANSACTION  - CONTRACT  LEVEL 

****  AUTOMATIC  COST  ACCRUAL  TRANSACTION  - PERFORMANCE  LEVEL 

*+**  COST  ACCRUAL  TRANSACTION  - FORM  100 

****  COST  ACCRUAL  TRANSACTION  - MANUAL 

Figure  2.8-6.  - Cost  Accrual  transaction-begun  messages. 

Code  Message 

A 000  TRANSACTION  COMPLETE 

Figure  2.8-7.  - Cost  Accrual  transaction-complete  messages. 


Code 


Message 


B 1 00  'as  OF'  DATE  INVALID 

B 1 01  'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE 

Bill  MA  INVALID 

B 1 21  PY  INVALID 

B 1 39  FS  INVALID 

B 17 1 PWC  INVALID 

B201  RESPONSIBLE  ORGANIZATION  INVALID 
B301  PURCHASE  REQUEST  NUMBER  INVALID 
B31 1 SUFFIX  INVALID 

B360  CONTRACT/ORDEB  NUMBER  NOT  ENTERED 

B361  CONTRACT/ORDEB  NUMBER  INVALID 

B380  CONTRACT  SCHEDULE  NUMBER  INVALID 

8440  TYPE  OF  COST  ACCRUAL  NOT  SPECIFIED 

B441  MULTIPLE  TYPE  OF  COST  ACCRUALS  SPECIFIED 

B442  TYPE  OF  COST  ACCRUAL  MUST  NOT  BE  SPECIFIED 

B450  RESPONSIBLE  COST  ACCOUNTANT  NOT  ENTERED 

8451  RESPONSIBLE  COST  ACCOUNTANT  INVALID 

B452  RESPONSIBLE  COST  ACCOUNTANT  MUST  BE  BLANK 

B460  CONTRACT  STATUS  NOT  SPECIFIED 

B461  CONTRACT  STATUS  INVALID 

B462  CONTRACT  STATUS  MUST  NOT  BE  'ACTIVE'  AND  'INACTIVE' 

B463  CONTRACT  STATUS  MUST  NOT  BE  SPECIFIED 

8470  BOTH  'CORRECTION'  AND  'DELETION'  MUST  NOT  BE  SPECIFIED 

B480  ACCRUAL  DATE  NOT  ENTERED 

B481  ACCRUAL  DATE  INVALID 

8490  CONTRACT  BEGINNING  DATE  INVALID 

B495  CONTRACT  ENDING  DATE  INVALID 

B600  $ AMOUNT  NOT  ENTERED 

B601  $ AMOUNT  INVALID 

B602  $ AMOUNT  MUST  NOT  BE  ZERO 

C500  PY  FS  COMBINATION  INVALID 

C508  PY  FS  COMBINATION  INVALID 


Figure  2.8-8.  - Cost  Accrual  data  element 
edit  error  messages. 


Code 


Message 


D 1 92  CONTRACT  RECORD  NOT  FOUND 

CONTRACT/ORDER  NO.  

D193  CONTRACT  RECORD  ALREADY  EXISTS 
CONTRACT/ORDER  NO. 

D 1 94  PERFORMANCE  DATA  RECORD  NOT  FOUND 

CONTRACT/ORDER  NO.  

D 1 95  COST  $ EXCEED  OBLIGATION  $ 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

COST  , , . OBLIGATION  $_, , , 

UPDATE  , , . 

D 1 96  DISBURSEMENT  $ EXCEED  COST  $ 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

DISBURSEMENT  $_, , , . COST  , , 

UPDATE  , , . 


Figure  2.8-9 


- Cost  Accrual  processing  error  messages 


Message  ABBBBBBBBBBBBBBBBBB 
0111111233333444444 

0001237001  668444555 

Transaction  0011191111010012012 


Contract  data 

Initial  establishment  XXX 
Update/Correction  XXX 
Deletion  XXX 
Automatic  accrual  X 


XX  XX  XX 

XX  XX  XX 

XX  X X 


Form  100  and  manual  accrual 

Initial  XXXXXXXXXXXXXXX 

Correction  XXXXXXXXXXXXXXX 


Message  B BB  BBBB  BBBBBCCDDDDD 
4444  44444666551  1 1 1 1 

6666788990000099999 
0 12300  10501  20823456 


Contract  data 
Initial  establishment 
Update/Correction 
Deletion 

Automatic  accrual 


Form  100  and  manual  accrual 

Initial 

Correction 


xxxx  X XXX 

XX  XX  XXX 


Figure  2.8-10.  - Cost  Accrual  messages  by  transaction. 


Inquiry  description 
Contract  level  cost 


Type 


Item  or 
summary 


Contract  status 


Item 


Contract  performance 
data 


List 


Input  data  elements 


Contract  number  and  any 

one  or  combination  of 

the  following: 

• Contract  Schedule 
Number 

• Primary  Work  Code 
(three,  four,  five, 
seven,  or  nine  digits) 

• Fund  Source 

• Program  Year 

• Method  of  Authority 

• Responsible  Organi- 
zation 

Contract  number 


Contract  number  and  one 

or  combination  of  the 

following: 

• Contract  Schedule 
Number 

• Primary  Work  Code 
(three,  four,  five, 
seven,  or  nine  digits) 

• Fund  Source 

• Program  Year 

• Method  of  Authority 

• Responsible  Organi- 
zation 


Timing  Response  data  elements 

Immediate  Contract  number  and  any  one  or 

combination  of  the  following: 

• Contract  Schedule  Number 

• Primary  Work  Code  (three, 
four,  five,  seven,  or  nine 
digits) 

• Fund  Source 

• Program  Year 

• Method  of  Authority 

• Responsible  Organization 
Cost 


Immediate  Contract  number 

Contract  Schedule  Number 
Cost  accrual  type 
Responsible  Cost  Accountant 
Contract  status  (active  or  inactive) 
Contract  Obligation 
Contract  Cost 
Contract  Disbursement 
Contract  Obligation  for  non- 
excluded  object  classes 
Contract  Cost  for  nonexcluded 
object  classes 

Immediate  All  PR's  for  a contract  with 

accounting  codes  and  the  commitment., 
obligation,  cost,  and  disburse- 
ment for  each 


Figure  2.8-11.  - Cost  Accrual  inquiry  requirements. 
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Inquiry  description 

Type 

Input  data  elements 

Timinq 

Response  data  elements 

Cost  PWC  inguiry  for 
contract  and  Reserva- 
tion Accounts  by 
Carrier  ID 

List 

PWC  (five  digits) 

Same  day 

PWC  (five  digits) 

Contract  number 

Directorate 

Cost 

Carrier  ID 

Reservation  Account  issues 

Assigned  contract 

List 

Responsible  Cost 
Accountant  code 

Overnight 

Responsible  Cost  Accountant  code 
Accrual  type 
Contract  number 
Contract  status 

Unassigned  contract 

List 

Accrual  type  (only  the 
type  accrual  showing 
no  assigned  type) 

Overnight 

Contract  number 

T’-order  obligation 
in  excess  of 
$150,000.00  where  no 
contract  data  exists 

List 

Hone  required 

Overnight 

T-order  number 
Object  Class 

Obligation  amount  (object  class) 
T-order  obligation  amount 

f 


r 


Figure  2.8-11.  - Cost  Accrual  inguiry  requirements  (concluded) 


2.9  COST  DISTRIBUTION  PROCESS 


The  Cost  Distribution  process  involves  the  distribution 
of  costs  from  a Carrier  account  entry  to  Reservation  PWA 
account  entries.  By  this  action,  appropriate  benefiting 
codes  and  RO  are  identified.  Costs  are  distributed  for 
services  and  supplies.  The  Cost  Accounting  Section  is 
responsible  for  monitoring  costs  distributed  from  the 
services  carriers,  and  the  Property  Accounting  Section  is 
responsible  for  the  monitoring  of  the  supply  carrier 
distribution. 

Monthly,  IFMS  receives  the  data  reguired  to  make  the 
distribution  of  costs  for  the  services  carriers  and  for  the 
supply  carrier  via  interfaces  with  four  other  computer 
systems.  The  Institutional  Management  Accounting  System 
Phase  A (IMAS-A) , the  Institutional  Management  Accounting 
System  Phase  B (IMAS-B) , and  the  Service  Center  Distribution 
System  (SCD)  provide  the  services  carriers  distribution 
data.  The  Supply  System  provides  the  data  for  the  supply 
carrier  distribution. 

Because  cost  distribution  data  is  supplied  to  IFMS  from 
external  sources  using  magnetic  tape,  the  data  will  be 
processed  in  a batch  environment.  Updates  and  corrections 
will  be  processed  in  the  online  environment. 

All  cost  distribution  data  require  the  update  of  the 
Carrier  and  Reservation  PWA  account  entries.  In  addition, 
the  performance  data  (commitment,  obligation,  cost,  and 
disbursement)  must  be  recorded  in  the  manner  necessary  to 
satisfy  external  interface  requirements  and  to  permit  the 


summarizations  required  for  reporting  purposes  (e.g.,  by 
PWC) . See  section  2.17  for  external  interface  requirements. 


2.9.1  Update  Requirements 

2 . 9 . 1 . 1 Distribution of services estimate.  At  the 

beginninq  of  each  fiscal  year,  estimated  costs  for  the 
Technical  Services  Carrier  (997-81) , the  Computer  Services 
Carrier  (997-82) , and  the  Maintenance  and  Repair  of 
Facilities  Carrier  (997-88)  will  be  generated  by  IMAS-B  and 
supplied  to  IFMS.  These  estimates  are  required  input 
because  of  a 30  day  lag  in  reporting  the  cost  of  services 
for  Carrier  funded  contracts.  At  the  end  of  the  fiscal 
year,  the  services  estimate  will  be  reversed  by  IMAS-B 
generated  data.  This  reversal  will  occur  after  all  costs 
have  been  input  for  the  fiscal  year.  The  reversal  will 
consider  the  beginni ng -of-year  estimate  and  any  adjustments 
to  the  estimate  made  during  the  fiscal  year. 

2. 9. 1.1.1  Initial  establishment:  The  beginning-of- 
year  services  estimate  and  end-of-year  reversal  will  consist 
of  two  transactions  related  to  one  another  by  a contract 
number.  (The  computer  services  carrier  estimate  will  have  a 
single  pseudo  contract  number  because  costs  reported  consist 
of  costs  for  several  contracts.)  The  first  is  a Carrier 
transaction  which  affects  a Carrier  account,  and  the  second 
is  a Cost  Distribution  transaction  which  affects  a 
Reservation  PWA  account  entry.  In  most  cases,  one  Carrier 
transaction  will  have  multiple  associated  Cost  Distribution 
transactions  with  each  Cost  Distribution  transaction  applied 
to  a Reservation  PWA  account  entry. 


IHEUi  - IFMS  will  validate  all  interface  data  to  insure 
that  the  data  is  the  desired  input.  Transaction  selection 
will  be  determined  by  an  "0"  and  "C"  specified  in  the 
identification  fields  along  with  a current  month  indicator. 
Since  the  Carrier  transaction  and  the  Cost  Distribution 
transaction  have  the  same  data  elements,  they  will  be 
described  together.  The  data  elements  and  edit  requirements 
are  shown  in  figure  2.9-1. 

EE226ssinq  - The  data  which  reflects  computer  services 
cost  from  IMAS-B  will  have  a Carrier  transaction  for  a 
contract  processed  with  that  contract's  Cost  Distribution 
transactions.  The  services  cost  will  have  multiple  Cost 
Distribution  transactions  associated  with  a single  Carrier 
transaction.  Depending  on  its  sign,  the  Carrier  transaction 
amount  will  be  used  to  increase  or  decrease  both  receipts 
and  issues  for  the  Carrier  account  entry.  From  the 
transaction,  the  Carrier  account  entry  will  be  identified  by 
MA,  PY,  FS,  R0,  and  the  first  five  digits  of  the  PWC. 
Depending  on  its  sign,  the  Cost  Distribution  transaction 
amount  will  result  in  an  increase  or  decrease  to  issues  in 
the  applicable  Reservation  PWA  account  entry.  From  the 
transaction,  the  Reservation  PWA  account  entry  will  be 
identified  by  HA,  PY,  FS,  RO,  the  first  five  digits  of  the 
PWC  if  FS  is  4 or  above  or  Object  Class  if  FS  is  3,  Carrier 
Identifier,  and  Carrier  RO.  Since  RO  on  the  Carrier 
transaction  reflects  the  Carrier  RO,  it  will  also  be  used  to 
identify  the  Reservation  PWA  account  entry.  Prior  fiscal 
year  Reservation  PWA  account  entries  for  FS  3 will  not  have 
Object  Class  as  part  of  the  identification.  The  Carrier  and 
Reservation  PWA  account  entries  to  be  updated  must  exist. 
The  Carrier  transaction  amount  must  not  reduce  the  Carrier 


ORIGINAL  I>AGBB 

OF  POOR  QUALITY! 


Data 

element 


Source 


Error 
t 1Q2.- 


Tr>jiH-/Edit  requirements 


to 


Primary  Work. 
Code 

Yes 

IMAS-B 

Fatal 

Responsible 

Organization 

Yes 

IMAS-B 

Fatal 

Object  Class 

Yes 

IMAS-B 

patal 

performing 

Organization 

Yes 

IMAS-B 

Fatal 

Primary  Job 
Code 

Conditional 

IMAS-B 

Fatal 

Secondary 
job  Code 

Conditional 

IMAS-B 

Fatal 

Carrier 

Identifier 

Yes 

IMAS-B 

Fatal 

Carrier 

Responsible 

Organization 

Generated 

System 

supplied 

None 

Contract 

number 

Yes 

IMAS-B 

Fatal 

Voucher 

number 

Yes 

IMAS-B 

Fatal 

Distributed 

dollars 

Yes 

IMAS-B 

Fatal 

Program  Year 

Yes 

IMAS-B 

Fatal 

Method  of 
Authority 

Yes 

IMAS-B 

Fatal 

Fund  Source 

Yes 

IMAS-B 

Fatal 

Edit 

First  five  digits  must  be  a 
valid  carrier  PVC. 

Must  be  a valid  P«C  tut  not  a 
Carrier  PNC. 

Must  be  a valid  R0- 


Transaction 

Carrier 

Cost  Distri- 
bution 


Must  be  a valid  Object  Class. 

Must  be  a valid  Performing  Organization. 


Recorded  if  provided  by  the  interface  system.  If 
the  first  digit  is  0 or  1,  must  be  a Centerwide 
Job  Code.  Also  validated  with  FS  and  Performing 
Organization . 

Recorded  if  provided  by  the  interface  system  and  the 
Primary  Job  Code  is  provided.  If  the  first  dxgit 
is  0 or  1,  must  be  a Centervide  Job  Code.  Also 
validated  vith  FS  and  Performing  Organization. 

Mhil*  input  for  all  transactions,  used  only  *lth 
the  Cost  Distribution  transaction.  Must  be  a valid 
Carrier  Identifier. 

Generated  for  the  Cost  Distribution  transaction  using 
the  carrier  transaction  related  bj  contract  number. 


If  the  first  digits  of  the  Carrier  Identifier  are 
997-82,  must  be  "SClim 

Must  be  J439. 


Must  be  numeric  and  not  equal  to  0. 


Bust  be  converted  to  a valid  Pi-  Uso  validated 
with  FS. 

Must  be  converted  to  a valid  MA. 

Must  be  a valid  FS.  Also  validated  with  PY. 


Error 

code 


8170 
B 171 


B200 

6201 

B190 

6191 

6320 

B321 

C506 

C507 

B330 

B331 

C506 


B340 

B341 

B342 

C507 

El  50 
B 1 51 


None 


B360 

6361 

B930 

B931 

B630 

B631 

B632 

B120 
E 1 21 

B110 

BUI 

Bl  30 
B139 
C500 
C506 
C507 


Figure  2.9-1. 


- Initial  Distribution  of  Services 


Estimate  input  and  edit  requirements. 


account  entry  receipts  below  0.  Carrier  account  entry 
issues  may  be  reduced  below  0 because  performance  data 
commtiments  which  affect  issues  in  a particular  Carrier 
account  entry  may  not  be  sufficient  to  offset  the  carrier 
reversal  amounts  shown  on  the  Carrier  transaction.  Another 
requirement  specifies  that  each  of  the  individual  Cost 
Distribution  transaction  amounts  when  applied  to  the  issues 
within  the  appropriate  Reservation  PWA  account  entry  must 
not  exceed  receipts  for  that  Reservation  PWA  account  entry. 
The  update  of  the  Reservation  PWA  account  entry  issues 
cannot  result  in  a negative  amount. 

Performance  data  input  for  Cost  Distribution  will  be 
recorded  at  the  PWC  summary  level  to  meet  reporting 
requirements.  All  performance  data  reflecting  a services 
estimate  will  be  recorded  with  an  indicator  specifying  that 
the  data  is  a services  estimate.  To  satisfy  audit  trail 
requirements,  each  transaction  will  be  recorded  in  a 
transaction  history. 

Output  - Section  2.9.4  describes  the  error  messages 
which  appear  on  error  reports  from  the  Distribution  of 
Services  Estimate  transaction. 

2.9. 1.1. 2 Update  and  correction:  After  establishing 

the  beginning-of-year  services  estimate,  changes  will  be 
necessary  because  additional  information  is  available  or 
because  errors  were  made  in  establishing  the  original 
estimate.  Updates  or  corrections  will  be  made  online. 

Input  - Both  the  Carrier  transaction  and  the  Cost 
Distribution  transaction  may  require  an  update  or  correction 


transaction.  Both  transactions  contain  the  same  input  data 
elements  and  are  described  in  figure  2.9-2.  Figure  2.9-3 
shows  the  template  required  for  input  of  these  data 
elements. 

Processing  - The  update  and  correction  processing 
requirements  are  the  same  as  those  for  the  initial 

establishment  of  the  Distribution  of  Services  Estimate 
transaction.  Section  2.9. 1.1.1  contains  a description  of 
these  requirements. 

Output  - Section  2.9.2  describes  the  error  messages 
which  will  appear  from  online  input  of  an  update  or 
correction  of  the  Distribution  of  Services  Estimate 
transaction. 


2.9. 1.2  Distribution  of  services.  Distribution  of  the 
services  carriers  cost  will  be  provided  by  the  interface 
systems  on  a monthly  basis.  The  SCD  will  generate  cost  data 
for  the  Computer  Services  Carrier  (997-82) ; IMAS-A  will 
generate  cost  data  for  the  Technical  Services  Carrier  (997- 
SI  ) and  the  Maintenance  and  Repair  of  Facilities  Carrier 
(997-88) ; IMAS-B  will  generate  estimated  costs  for  missing 
monthly  data  not  reported  for  997-81,  997-82,  or  997-88 
Carrier  account  entries. 

2.9. 1.2.1  Initial  establishment:  As  in  the  case  of 
the  Services  Estimate  transaction,  two  types  of  data  will  be 
input:  the  Carrier  transaction  and  the  Cost  Distribution 
transaction  which  are  related  to  one  another  by  contract 
number.  (Computer  services  data  will  show  only  a single 
pseudo  contract  number.)  Also,  the  Carrier  transaction  will 

2.9-6 


9-7 


Data 

element 

Element 

required 

Source 

Error 

type 

Inout/Edit  requirements 

Error 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 01 

Method  of 
Authority 

Yes 

User  supplied 

Fatal 

Must  be  a valid  MA. 

B 1 1 0 
Bill 

Program  Year 

Yes 

User  supplied 

Fatal 

Must  be  a valid  PY.  Also  validated  with  FS. 

B120 
B 1 21 
C508 

Fund  Source 

Yes 

User  supplied 

Fatal 

Must  be  a valid  FS.  Also  validated  with  PY. 

B130 

B139 

CS08 

C509 

C510 

Primary  Work 
Code 

Yes 

User  supplied 

Fatal 

Transaction  Edit 

Carrier  First  five  digits  must  be  a 

valid  Carrier  PRC. 

Cost  Distri-  Must  be  a valid  PWC  but  not 

bution  a Carrier  PWC. 

B170 

B171 

Object  Class 

Yes 

User  supplied 

Fatal 

Must  be  a valid  Object  Class. 

B190 

B191 

Responsible 

Organization 

Yes 

User  supplied 

Fatal 

Must  be  a valid  funding  RO. 

B200 

B204 

B206 

Carrier 

Identifier 

Conditional 

User  supplied 

Fatal 

Input  only  for  the  Cost  Distribution  transaction. 
Must  be  a valid  Carrier  Identifier. 

B150 

B151 

B153 

Carrier 

Responsible 

Organization 

Conditional 

User  supplied 

Fatal 

Input  only  for  the  Cost  Distribution  transaction. 
Must  be  a valid  Carrier  RO. 

B210 

B211 

B212 

Contract 

numher 

Yes 

User  supplied 

Fatal 

If  the  first  digits  of  the  Carrier  Identifier  are 
997-82,  must  be  "SC77777." 

B360 

B361 

Performing 

Organization 

Yes 

User  supplied 

Fatal 

Must  be  a valid  Performing  Organization. 

B320 

B323 

C509 

C510 

Primary  Job 
Code 

Conditional 

user  supplied 

Fatal 

If  the  first  aigit  is  0 or  1 , must  be  a Center- 
wide Job  Code.  Also  validated  with  FS  and  Per- 
forming Organization. 

B330 

B331 

C509 

Figure  2.9-2.  - Distribution  of  Services  Estimate  update  and  correction  input  and  edit  requirements. 
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required 
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Error 

type 


Error 

code 


Secondary 
Job  Code 

Conditional 

User  supplied 

Fatal 

If  input.  Primary  Job  Code  must  be  input.  If  the 
first  digit  is  0 or  1,  must  be  a Centerwide  Job 
Code.  Also  validated  with  FS  and  Performing  Orga- 
nization. 

B340 

B341 

B342 

C510 

Supply 

document 

No 

Hone 

Fatal 

Must  not  be  input  for  Distribution  of  Services 
Estimate  update  or  correction  transactions. 

B502 

number 

Voucher 

number 

Generated 

System 

supplied 

None 

Must  be  J439. 

None 

Distributed 

dollars 

Yes 

User  supplied 

Fatal 

Must  be  numeric  and  not  egual  to  0. 

B630 

B631 

B632 

Type  of 
distribution 

Yes 

User  supplied 

Fatal 

Transaction  indicator  must  be  input  as  a * services 
estimate*. 

8010 
B0 1 1 

Correction 

indicator 

Conditional 

User  supplied 

None 

Transaction  modifier.  Input  only  when  correcting 
previous  online  input. 

None 

f 


Figure  2.9-2. 


- Distribution  of  Services  Estimate  update  a 


nd  correction  input  ana  edit  requirements  (concluaea) . 


****IFHS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  L2  - COST  DISTRIBUTION 

MA PY IS PWC  OBJECT  CLASS 

RESP  ORG CARRIER  ID  CARRIER  RESP  ORG 

CONTRACT  NO.  PERF  ORG  

PRIMARY  JOB  CODE  SECONDARY  JOB  CODE  

SUPPLY  DOC  NO.  

DISTRIBUTED  $ , , . ± 

TYPE  OF  DISTRIBUTION: 

SERVICES  ESTIMATE  _ SERVICES 
SUPPLY  CORRECTION  _ SUPPLY  ADJUSTMENT 
CORRECTION 


Figure  2.9-3 


Cost  Distribution  template 


and  the  Cost  Distribution 


affect  a Carrier  account, 
transaction  will  affect  a Reservation  PWA  account  entry. 

iS-EUi  “ As  in  the  case  of  the  Services  Estimate 
transaction,  IFMS  will  validate  all  interface  data  to  insure 
that  the  data  is  the  desired  input.  Transaction  selection 
will  be  determined  by  an  "O’  and  "9M  specified  in  the 
identification  fields  along  with  the  current  month 
indicator.  A description  of  the  data  elements  and  edit 
requirements  for  the  Carrier  transaction  and  the  Cost 
Distribution  transaction  is  shown  in  figure  2.9-4. 

Processing  - The  Initial  Distribution  of  Services 
transaction  contains  the  same  processing  requirements  as  the 
initial  establishment  of  the  Distribution  of  Services 
Estimate  transaction.  Section  2. 9. 1.1.1  contains  a 
description  of  these  requirements. 

Output  - Section  2.9.4  describes  the  error  messages 
which  will  appear  on  error  reports  from  the  Distribution  of 
Services  transaction. 

2. 9.  1.2. 2 Update  and  correction:  Because  of  incorrect 
or  missing  data  involving  cost  for  services,  an  update  or 
correction  will  be  necessary  to  correct  this  data  and  will 
be  made  online. 

Input  - Both  the  Carrier  transaction  and  the  Cost 
Distribution  transaction  may  require  update  or  correction 
transactions.  Figure  2.9-5  shows  the  input  data  elements 
and  data  edits  required  for  a Carrier  transaction  or  a Cost 
Distribution  transaction.  Figure  2.9-3  defines  the  template 
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Data 

element 

Element 

required 

Source 

Primary  Work 
Code 

Yes 

SCD , IMAS-A, 
IMAS-B 

Responsible 

organization 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Object  Class 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Performing 

Organization 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Primary  Job 
Code 

Conditional 

SCD,  IMAS-A 
IMAS-B 

Secondary 
Job  Code 

Conditional 

SCD,  IM AS- A , 
IMAS-B 

Carrier 

Identifier 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Carrier 

Responsible 

Organization 

Generated 

System 

supplied 

Contract 

number 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Voucher 

number 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Distributed 

dollars 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Program  Year 

Yes 

SCD,  IMAS-A, 
IMAS-B 

Method  of 
Authority 

Yes 

SCD,  IMAS-A 
IMAS-B 

Fund  Source 

Yes 

SCD,  IMAS-A 
IMAS-B 

Figure  2.9-4 


Initial 


Error 

Error  . . . r-oflp 

type  Inout/Edxt  requirements  cooe_ 

Fatal  Transaction  n171 

Carrier  First  fave  digits  must  be  a 

valid  carrier  PWC. 

Cost  Distri—  Must  be  a valid  PWC  blit  not 
bution  a carrier  PWC. 

Fatal  Must  be  a valid  HO-  B2G1 

Fatal  Must  be  a valid  Object  Class.  ^190 

Fatal  Must  be  a valid  Performing  Organization.  B320 

C506 

C507 

Fatal  Recorded  if  provided  by  the  interface  system.  r^i 

If  the  first  digit  is  0 or  1,  must  be  a Center- 
wide  Job  Code.  Also  validated  with  FS  and  C506 

Performing  Organization. 

Fatal  Recorded  if  provided  by  the  interface  system  B340 

and  a Primary  Job  Code  is  provided.  If  the  ' 

first  digit  is  0 or  1,  must  be  a Centerwide 

job  Code.  Also  validated  with  FS  and  Per-  C507 

forming  organization. 

Fatal  While  input  for  all  transactions,  used  only  *ith 

the  Cost  Distribution  transaction^  Must  be  a valid  btsi 

Carrier  Identifier. 

None  Generated  for  the  Cost  Distribution  transaction  using  None 

the  Carrier  transaction  related  by  contract  number. 

Fatal  If  the  first  digits  of  the  Carrier  Identifier  are  B360 

997-82,  must  be  "SC77777."  8361 

Fatal  Must  be  J439. 

Fatal  Must  be  numeric  and  not  egual  to  0.  B631 

B632 

Fatal  Must  be  converted  to  a valid  PY.  Also  validated  B120 

with  FS.  C500 

Patal  Must  be  converted  to  a valid  MA. 

Fatal  Must  be  a valid  FS.  Also  validated  with  PY.  B130 

C500 

C506 

C507 


distribution  of  Services  input  and  edit  requirements. 


Data 

element 

Element 

required 

Source 

Error 
t IE§_ 

'As  of' 
Date 

Optional 

User  supplied 

Fatal 

Hethod  of 
Authority 

Yes 

User  ^supplied 

Fatal 

Program  Year 

Yes 

User  supplied 

Fatal 

Fund  Source 

Yes 

User  supplied 

Fatal 

Primary  Work 
Code 

Yes 

User  supplied 

Fatal 

Object  Class 

Yes 

User  supplied 

Fatal 

Responsible 

Organization 

Yes 

User  supplied 

Fatal 

Carrier 

Identifier 

Conditional 

User  supplied 

Fatal 

Carrier 

Responsible 

Organization 

Conditional 

User  supplied 

Fatal 

Contract 

number 

Yes 

User  supplied 

Fatal 

/' 


Figure  2.9-5. 


Input/Edit  requirements 


Error 

code 


Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

Must  be  a valid  MR.  B110 

Bill 

Must  be  a valid  PY.  Also  validated  with  FS.  B120 

B 1 2 1 
C508 

Must  be  a valid  FS.  Also  validated  with  PY.  B130 


B139 
C508 
C509 
C5 1 0 


Transaction  Edit  B 1 7 0 

Carrier  First  five  digits  must  be  B171 

a valid  Carrier  PWC. 

Cost  Distri-  Must  be  a valid  PWC  but 
bution  not  a Carrier  PWC. 

Must  be  a valid  Object  Class.  B190 

B 1 9 1 

Must  be  a valid  funding  HO.  B200 

B20  4 
B206 

Input  only  for  the  Cost  Distribution  transaction.  B150 

Must  be  a valid  Carrier  Identifier.  B151 

B153 


Input  only  for  the  Cost  Distribution  transaction.  B210 

Must  be  a valid  Carrier  RO.  0211 

B212 


If  the  first  digits  of  the  Carrier  Identifier  are  B360 

997-82,  must  be  "SC77777".  B361 


pdate  and  correction  input  and  edit  requirements. 
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/ 


Data 

element 

Element 

required 

Source 

Error 

type_ 

Fatal 

Input/Edit  requirements 

Error 

code 

Performing 

Organization 

Yes 

User  supplied 

Must  be  a valid  Performing  Organization. 

B320 

B323 

C509 

C510 

Primary  Job 
Code 

Conditional 

User  supplied 

Fatal 

If  the  first  digit  is  0 or  1 , must  be  a Centerwide 
Job  Code.  Also  validated  with  FS  and  Performing 
Organization . 

B330 
B33 1 
C509 

Secondary 
Job  Code 

Conditional 

User  supplied 

Fatal 

If  input.  Primary  Job  Code  must  be  input.  If  the 
first  digit  is  0 or  1,  must  be  a Centerwide  Job 
Code.  Also  validated  with  FS  and  Performing  Orga- 
nization. 

B340 
B341 
B342 
C51  0 

Supply 

document 

number 

No 

None 

Fatal 

Must  not  be  input  for  Distribution  of  Services 
update  or  correction  transactions. 

B502 

Voucher 

number 

Generated 

System 

supplied 

None 

Must  be  J439. 

None 

Distributed 

dollars 

Yes 

User  supplied 

Fatal 

Must  be  numeric  and  not  egual  to  0. 

B600 

B601 

B602 

Type  of 
distribution 

Yes 

User  supplied 

Fatal 

Transaction  indicator  must  be  input  as  'services*. 

B0 1 0 
B011 

Correction 

Indicator 

Conditional 

User  supplied 

None 

Transaction  modifier.  Input  only  when  correcting 
previous  online  input. 

None 

Figure  2.9-5.  - Distribution  of  Services  update  and  correction  input  and  edit  requirements  (concluded) . 


required  for  "the  input  of  the  data  elements. 


Processing  - The  Distribution  of  Services  update  and 
correction  transaction  contains  the  same  processing 
requirements  as  the  initial  establishment  of  the 
Distribution  of  Services  Estimate  transaction.  Section 
2.9.  1.1.1  contains  a description  of  these  requirements. 

Output  - Section  2.9.2  describes  the  error  messages 
which  will  appear  cn  reports  from  the  Distribution  of 
Services  update  and  correction  transaction. 

2. 9. 1.3  Distribution  of  supplies.  Distribution  of  the 
supply  carrier  cost  will  be  provided  by  the  Supply  System 
interface  on  a monthly  basis.  Processing  of  the  interface 
data  will  be  accomplished  in  the  batch  environment.  Also, 
corrections  and  adjustments  will  be  made  onlxne  periodically 
during  the  month. 

2. 9. 1.3.1  Initial  establishment:  As  in  the  case  of 
the  other  Cost  Distribution  transactions,  the  Carrier 
transaction  and  the  Cost  Distribution  transaction  are 
generated  by  the  Supply  System  interface.  No  contract 
number  relationship  exists  for  these  transactions.  The 
Carrier  transaction  will  affect  the  supply  Carrier  account 
entry,  and  the  Cost  Distribution  transaction  will  affect  the 
Reservation  pwA  account  entry. 

Input  - As  in  the  case  of  the  other  Cost  Distribution 
transactions,  IFMS  will  validate  all  interface  data  to 
insure  that  the  data  is  the  desired  input.  Selection  will 
be  determined  by  an  "R"  specifying  each  transaction 
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identification  field  along  with  a current  month  indicator. 

A description  of  the  data  elements  and  edit  requirements  for 
the  Carrier  transaction  and  the  Cost  Distribution 
transaction  are  shown  in  figure  2.9-6. 

- Depending  on  its  sign,  the  Carrier 
transaction  amount  will  be  used  to  increase  or  decrease  both 
receipts  and  issues  of  the  Carrier  account  entry  identified 
by  MA,  PY,  FS,  RO,  and  the  first  five  digits  of  the  PWC. 
Depending  on  its  sign,  the  Cost  Distribution  transaction 
amount  will  result  in  an  increase  or  decrease  to  issues  in 
the  applicable  Reservation  PWA  account  entry  identified  by 
the  input  HA,  PY,  FS,  RO,  the  first  five  digits  of  the  PWC 
if  FS  is  4 or  above  or  Object  Class  if  FS  is  3,  Carrier 
Identifier,  and  Carrier  RO.  Prior  fiscal  year  Reservation 
PWA  account  entries  for  FS  3 will  not  have  Object  Class  as 
part  of  the  identifying  information.  The  Carrier  and 
Reservation  PWA  account  entries  must  exist.  The  Carrier 
transaction  amount  must  not  reduce  the  Carrier  account 
receipts  below  0.  Carrier  account  entry  issues  may  be 
reduced  below  0,  because  the  performance  data  commitments 
which  affect  issues  in  a particular  Carrier  account  entry 
may  not  be  sufficient  to  offset  the  Carrier  reversal  amounts 
shown  on  the  Carrier  transaction.  Another  requirement 
specifies  that  each  of  the  individual  Cost  Distribution 
transaction  amounts  when  applied  to  the  Reservation  PWA 
account  entry  issues  must  not  result  in  the  issues  exceeding 
-the  receipts  or  result  in  the  issues  becoming  negative. 

The  Distribution  of  Supplies  transaction  processing 
requirements  defined  above  do  not  apply  when  the  recipient 
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Data 

element 

Method  of 
Authority 

Element 

required 

Yes 

Source 

Error 

tvne 

Innut/Edit  requirements 

Supply 

Fatal 

Must  be  a valid  MA. 

Program  Year 

Yes 

Supply 

Fatal 

Must  be  able  to  be  converted  to  a valid  PY. 
Also  validated  with  FS. 

Fund  Source 

Yes 

Supply 

Fatal 

Must  be  a valid  FS.  Also  validated  with  PY. 

Primacy  Work 
Code 

Yes 

Supply 

Fatal 

Transaction  Edit 

Carrier  First  five  digits  m-ust  be 

a valid  Carrier  PWC. 

Cost  Distri-  Must  be  a valid  PWC  but 

bution  not  a Carrier  PWC. 

Responsible 

Organization 

Yes 

Supply 

Fatal 

Must  be  a valid  BO. 

Object  Class 

Yes 

Supply 

Fatal 

Must  be  a valid  Object  Class. 

Performing 

Organization 

Yes 

Supply 

Fatal 

Must  be  a valid  Performing  Organization. 

Primary  Job 
Code 

Conditional 

Supply 

Fatal 

Recorded  if  provided  by  the  interface  system. 

If  the  first  digit  is  0 or  1,  must  be  a Centerwide 
Job  Code.  Also  validated  with  FS  ana  Performing 
Organization. 

Secondary 
job  Code 

Conditional 

Supply 

Fatal 

Recorded  if  provided  by  the  interface  system  and 
a Primary  Job  Code  is  provided.  If  the  first 
digit  is  0 or  1,  must  be  a Centerwide  Job  Code. 

Also  validated  with  PS  and  Performing  Organization. 

Carrier 

identifier 

Generated 

System 

supplied 

None 

Supply  Carrier  Identifier  is  generated  for  the  Cost 
Distribution  transaction. 

Carrier 

Fesponsible 

organization 

Generated 

System 

None 

Supply  Carrier  RC  is  generated  for  the  Cost  Distri- 
bution transaction. 

Supply 

document 

number 

Yes 

Supply 

Fatal 

Transaction  Edit 

Carrier  Must  be  blank. 

Cost  Distri-  Must  be  numeric, 

bution 

Voucher 

number 

Yes 

Supply 

Fatal 

The  first  digits  .must  be  J4660.  The  last  digit  must 
be  1,  2,  or  3. 

Distributed 

dqllars 

Yes 

Supply 

Fatal 

Must  be  numeric  and  not  equal  to  0. 

Figure  2.9-6.  - Initial  Distribution  of  Supplies  input  ana  edit  requirements. 


Error 

code 


3110 

Bill 

B120 

B121 

C500 

B130 

B139 

C500 

C506 

C507 

B 170 
B 171 


B200 

B201 

B 190 
B191 

B320 

B321 

C506 

C507 

B330 

B331 

C506 


B340 
B34 1 
B342 
C507 

None 


None 


B501 

B502 


B930 

B931 

B933 

B600 
B60 1 
B602 


of  the  Cost  Distribution  transaction  is  the  Computer 
Services  Carrier  (i.e.,  the  first  five  digits  of  the  PWC  are 
997-82) . Instead,  the  following  requirements  are 
applicable.  First,  issues  in  the  Reservation  PWA  account 
entry  identified  by  an  MA  of  00,  an  RO  of  FD,  a current  PY, 
an  FS  of  9,  a PWC  of  997-82,  a Carrier  Identifier  of  998-00, 
and  a Carrier  RO  of  JF  are  updated.  Issues  in  the  account 
entry  are  increased  or  decreased,  depending  on  the  sign  of 
the  transaction  amount.  Issues  in  the  account  entry  must 
not  exceed  receipts,  nor  can  issues  result  in  a negative 
amount.  Second,  the  Computer  Services  Carrier  account  entry 
is  also  updated.  This  account  entry  is  identified  by  an  MA 
of  00,  a Carrier  PO  of  FD,  a current  PY,  a FS  of  9,  and  a 
PWC  of  997-82.  Issues  are  increased  or  decreased,  depending 
on  the  sign  of  the  transaction  amount.  Issues  in  this 
account  entry  may  result  in  a negative  amount  but  must  net 
exceed  receipts.  Third,  a particular  RA  account  entry  is 
updated  and  is  identified  by  an  MA  of  00,  an  FS  of  9,  a 
current  PY,  and  a PWC  of  997.  Issues  in  this  account  entry 
are  increased  if  the  sign  of  the  transaction  amount  is 
negative  or  decreased  if  the  sign  of  the  transaction  amount 
is  positive.  The  update  of  this  RA  account  entry  must  not 
result  in  a negative  issues  amount.  Fourth,  an  Allotment 
account  is  updated  and  is  identified  by  an  MA  of  00,  an  FS 
of  9,  and  a current  PY.  Issues  in  this  account  entry  are 
increased  if  the  sign  of  the  transaction  amount  is  negative 
or  decreased  if  the  sign  of  the  transaction  amount  is 
positive.  The  update  of  this  account  entry  must  not  result 
in  a negative  issues  amount. 

As  in  the  case  of  the  performance  data  for  the  services 
carriers,  the  Distribution  of  Supplies  transaction  data  will 
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be  recorded  at  the  PWC  summary  level  to  meet  reporting 
requirements.  All  performance  data  reflecting  a 
distribution  of  supplies  will  be  recorded  with  an  indicator 
specifying  that  the  data  is  a distribution  of  supplies.  To 
satisfy  audit  trail  requirements,  each  transaction  will  be 
recorded  on  a transaction  history. 

Output  - Section  2.9.4  describes  the  error  messages 
which  will  appear  on  error  reports  from  the  Distribution  of 
Supplies  transaction. 

2.9. 1.3.2  Update  and  correction:  After  the 
establishment  of  the  monthly  supply  distribution, 
adjustments,  called  supply  corrections,  are  made  because  of 
an  error  in  the  supply  distribution.  Also,  changes  may  be 
necessary  because  additional  information  is  available. 
These  changes  can  be  the  result  of  (1)  inventory  adjustments 
due  to  an  actual  count  of  inventory  on  hand,  (2)  inventory 
disposal,  the  actual  transfer  of  dollar  amounts  of 
inventory,  or  (3)  the  process  of  reconciling  receipts  within 
the  Supply  System  to  the  FMD  accounting  system. 

Input  - Both  the  Cost  Distribution  transaction  and  the 
Carrier  transaction  for  update  and  correction  will  be  input 
online.  Both  transactions  have  the  same  input  data  elements 
and  edit  requirements  and  are  shown  in  figure  2.9-7,  Figure 
2. 9-3  shows  the  input  template  for  data  elements. 

Processing  - The  update  and  correction  processing 
requirements  are  the  same  as  those  for  the  initial 
establishment  of  the  Distribution  of  Supplies  described  in 
section  2.9. 1.3.1. 
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$ $ 


Data 

element 

'As  of1 
Date 

Element 

required 

Source 

Error 

type 

Fatal 

Input/Edit  requirements 

Error 

code 

Optional 

User  supplied 

Date  providing  for  the  backdating  of  transactions,, 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Method  of 
Authority 

Yes 

User  supplied 

Fatal 

Must  be  a valid  HA. 

B 1 00 
Bill 

Program  Year 

Yes 

User  supplied 

Fatal 

Must  be  a valid  PY.  Also  validated  with  FS. 

B 1 20 
B121 
B 1 22 
C508 

Fund  Source 

Yes 

User  supplied 

Fatal 

Must  be  a valid  FS.  Also  validated  with  PY. 

B 1 30 
B'l  39 
C508 
C509 
C510 

Primary  Work 
Code 

Yes 

User  supplied 

Fatal 

Transaction  Edit 

Carrier  First  five  digits  must  be 

a valid  Carrier  PWC. 

Cost  Distri-  Must  be  a valid  PWC  but 

bution  not  a Carrier  PWC. 

B17  0 
B 17  1 

Object  Class 

Yes 

User  supplied 

Fatal 

Must  be  a valid  Object  Class. 

B 1 90 
B191 

Responsible 

Organization 

Yes 

User  supplied 

Fatal 

Must  be  a valid  funding  RO. 

B200 
B 20  1 

Carrier 

Identifier 

Conditional 

User  supplied 

Fatal 

Input  only  for  the  Cost  Distribution  transaction. 
Must  be  a valid  Carrier  Identifier. 

B 1 50 
B 1 51 
B1  53 

Carrier 

Responsible 

Organization 

Conditional 

User  supplied 

Fatal 

Input  only  for  the  Cost  Distribution  transaction. 
Must  be  a valid  Carrier  RO. 

B210 

B211 

B212 

Contract 

number 

Conditional 

User  supplied 

Fatal 

Not  input  for  supply  correction.  Must  be  present 
for  supply  adjustment. 

B360 

B361 

B362 

Figure  2,9-7.  - Distribution  of  Supplies  update  and  correction  input  and  edit  requirements. 


Data 

element 

Element 

required 

Source 

Error 

t2E§_ 

Input/Edit  requirements 

Performing 

Organiztion 

Yes 

User  supplied 

Fatal 

Must  be  a valid  Performing  Organization. 

Primary  Job 
Code 

Conditional 

User  supplied 

Fatal 

If  the  first  digit  is  0 or  1 , must  be  a Center- 
terwide  Job  Code.  Also  validated  with  FS  and  Per- 
forming Organization. 

Secondary 
Job  Code 

Conditional 

User  supplied 

Fatal 

If  input r Primary  Job  Code  must  be  input.  If  the 
first  digit  is  0 or  1,  must  be  a Centerwide  Job 
Code.  Also  validated  with  FS  and  Performing  Orga- 
nization. 

Supply 

document 

number 

Yes 

User  supplied 

Fatal 

Must  be  numeric.  Positions  2 through  4 must  be 
in  the  range  001  through  366. 

Distributed 

dollars 

Yes 

User  supplied 

Fatal 

Must  be  numeric  and  not  equal  to  0. 

Type  of 
distribution 

Yes 

User  supplied 

Fatal 

Transaction  indicator.  Must  be  input  as  supply 
correction  or  supply  inventory  adjustment. 

Correction 

indicator 

Conditional 

User  supplied 

None 

Transaction  modifier.  Input  only  when  correcting 
previous  online  input. 

Figure  2,9-7.  - Distribution  of  Supplies  update  and  correction  input  and  edit  requirements  (concluded) . 


Error 

code 


B320 
E323 
C509 
C 5 1 0 

B330 

B331 

C509 

B3**G 

B341 

B342 

C510 


B500 
B 50 1 


B600 
B 60  1 
B602 

B0 1 0 
BO  1 1 


None 


Output  - Section  2.9.2  describes  the  error  messages 
which  will  appear  from  the  Distribution  of  Supplies  update 
and  correction  transaction. 

2.9.2  Output  Message  Requirements 

Figures  2.9-8  through  2.9-11  contain  a list  of  output 
message  requirements.  Figure  2.9-12  contains  a correlation 
of  output  messages  by  Cost  Distribution  process  transaction. 

2.9.3  Inguiry  Requirements 

Figure  2.9-13  contains  a list  of  inquiry  input  data 
elements  and  response  data  elements  required  for  the  Cost 
Distribution  process. 

2.9.4  Report  Requirements 

The  Cost  Distribution  process  report  requirements  can 
be  found  in  sections  2.19.3  and  2.19.6.  Within  section 
2.19.3  are  reports  that  reflect  performance  data  for 
distribution  of  services  and  that  reflect  the  status  of 
Reservation  PWA  account  entries.  The  following  reports  are 
included: 


• Distribution  of  Services  Year-To-Date  Cost  Amounts 

• Reservation  PWA  by  Carrier 

The  Inventory  Reconciliation  report  described  within  section 
2.19.6  will  be  used  to  determine  adjustments  to  the  supply 
carrier.  Reports  which  show  transaction  data  for  both  batch 


Message 


Code 

****  COST  ESTIMATE  TRANSACTION 

****  COST  ESTIMATE  TRANSACTION  - CORRECTION 

1 

****  SERVICES  TRANSACTION  ] 

****  SERVICES  TRANSACTION  - CORRECTION  1 

****  SUPPLY  CORRECTION  TRANSACTION 

****  SUPPLY  CORRECTION  TRANSACTION  - CORRECTION 

****  SUPPLY  ADJUSTMENT  TRANSACTION 

****  SUPPLY  ADJUSTMENT  TRANSACTION  - CORRECTION 

B010  TYPE  OF  TRANSACTION  NOT  SPECIFIED 

B0 1 1 MULTIPLE  TYPES  OF  TRANSACTION  SPECIFIED 

''I 

Figure  2.9-8.  - Cost  Distribution  j 

transaction-begun  messages. 

1 

1 

} i 

Code  Message  \ 

•jj 

A000  Processing  Complete  1 

1 

Figure  2.9-9.  - Cost  Distribution  j 

transaction-complete  messages-  j 
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i 
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Code  Message 

B 1 00  MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

B 1 22  PY  MUST  BE  6M  OR  58  TO  CURRENT  FISCAL  YEAR 

B 1 30  FT3  NOT  ENTERED 

B 1 39  FS  INVALID 

B 1 50  CARRIER  ID  NOT  ENTERED 

B 1 51  CARRIER  ID  INVALID 

B 1 52  CARRIER  ID  MUST  BE  BLANK 

B 1 7 0 PNC  NOT  ENTERED 

B 171  PWC  INVALID 

B 1 90  OBJECT  CLASS  NOT  ENTERED 

B 1 9 1 OBJECT  CLASS  INVALID 

B200  RESPONSIBLE  ORGANIZATION  NOT  ENTERED 

B201  RESPONSIBLE  ORGANIZATION  INVALID 

B204  RESPONSIBLE  ORGANIZATION  INVALID 

B.2  06  RESPONSIBLE  ORGANIZATION  MUST  BE  A FUNDING  $0 

B 2 1 0 CARRIER  RO  NOT  ENTERED 

B 2 1 1 CARRIER  RO  INVALID 

B212  CARRIER  RO  MUST  BE  BLANK 

B320  PERFORMING  ORGANIZATION  NOT  ENTERED 

B 32 1 PERFORMING  ORGANIZATION  INVALID 

B323  PERFORMING  ORGANIZATION  INVALID 

B330  PRIMARY  JOB  CODE  INVALID 

B 33 1 PRIMARY  JOB  CODE  MUST  BE  CENTERWIDE  JOB  CODE 

B340  SECONDARY  JOB  CODE  INVALID 

B341  SECONDARY  JOB  CODE  MUST  BE  BLANK 

B 342  SECONDARY  JOB  CODE  MUST  BE  CENTERWIDE  JOB  CODE 

B360  CONTRACT/ORDER  NUMBER  NOT  ENTERED 

B3  61  CONTRACT/ORDER  NUMBER  INVALID 

B362  CONTRACT/ORDER  NUMBER  MUST  BE  BLANK 


Figure  2. 9-10.  - Cost  Distribution  data  element 
edit  error  messages. 
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Message 


Code 

B500  SUPPLY  DOCUMENT  NUMBER  NOT  ENTERED 

B501  SUPPLY  DOCUMENT  NUMBER  INVALID 

B502  SUPPLY  DOCUMENT  NUMBER  MUST  BE  BLANK 

B600  $ AMOUNT  NOT  ENTERED 

D601  $ AMOUNT  INVALID 

B602  $ AMOUNT  MUST  NOT  BE  ZERO 

B930  VOUCHER  NUMBER  NOT  ENTERED 

B 93 1 VOUCHER  NUMBER  INVALID 

B933  VOUCHER  NUMBER  MUST  BE  GREATER  THAN  ZERO 
C500  PY  PS  COMBINATION  INVALID 

C506  PS,  PERP  ORG,  PRIMARY  JOB  CODE  COMBINATION  INVALID 

C507  FS,  PERF  ORG,  SECONDARY  JOB  CODE  COMBINATION  INVALID 

0508  PY  FS  COMBINATION  INVALID 

0509  FS , PERF  CRG , PRIMARY  JOB  CODE COMBINATION  INVALID 

0510  FS , PERF  CRG , SECONDARY  JOB  CODE COMBINATION  INVALID 


Figure  2.9-10.  - Cost  Distribution  data  element 
edit  error  messages  (concluded)  . 
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■j? 


Code 


D100  RESOURCES  AUTHORITY  RECORD  NOT  FOUND 

MA PY FS PWC  

D102  RESOURCES  AUTHORITY  ISSUES  INSUFFICIENT 
MA PY FS PWC  

ISSUES  , , . UPDATE  $ . , . - 

D 1 03  RESOURCES  AUTHORITY  BALANCE  INSUFFICIENT  TO  ISSUE  PWA 
MA  __  PY FS PWC  

BALANCE  , , . UPDATE  $_, , , . - 

D 1 40  PWA  RECORD  NOT  FOUND 

MA PY FS RO PWC 

OBJECT  CLASS  CARRIER  ID  SUB  ID 

D 1 42  PWA  ISSUES  INSUFFICIENT 

MA PY FS RO PWC  

OBJECT  CLASS  CARRIER  ID  SUB  ID 

ISSUES  , , . UPDATE  , , . - 

D 1 43  PWA  BALANCE  INSUFFICIENT  TO  INCREASE  ISSUES 

MA PY FS RO PWC  _____ 

OBJECT  CLASS  CARRIER  ID  SUB  ID 

BALANCE  $_, , , . UPDATE  $_, , , . 

D150  CARRIER  RECORD  NOT  FOUND 

MA PY FS CARRIER  ID 

D153  CARRIER  BALANCE  INSUFFFICIENT  TO  INCREASE  ISSUES 
MA PY FS CARRIER  ID 

BALANCE  , , . UPDATE  , , . 

D 1 54  CARRIER  RECEIPTS  INSUFFICIENT 

MA PY FS CARRIER  ID 

RECEIPTS  $_, , , . UPDATE  $_, , - 


Figure  2.9-11.  - Cost  Distribution  processing  error  messages. 
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Transaction 


Message  A B 
0 0 
0 1 
0 0 


B B B B B 

0 1111 
1112  2 
10  10  1 


B B B B 
1111 
2 3 3 5 
2 0 9 0 


B B B E B 
11111 
5 5 7 7 9 
12  0 10 


B B B B B 
1 2 2 2 2 
9 0 0 0 0 
10  14  6 


B B B B B 
2 2 2 3 3 
1112  2 
0 12  0 1 


B B B B B 

3 3 3 3 3 

2 3 3 4 4 

3 0 10  1 


Services  estimate 
Initial  (batch) 

Update  and  correction 
(online) 

Services 
Initial  (batch) 

Update  and  correction 
(online) 


X X X X X 

X X X X X X X 


X X X X X 

X X X X X X X 


XXXX  XX  X x 

xxxxxxxxx 


X X 

X XX 


X X 

XXXX 


XXXX 
X X X X X 


XXXX  XXXX 

xxxxxx  xxx 


X x 

X X X X x X 


XX  XXXX 

X X X X X X 


Supplies 
Initial  (batch) 

Update  and  correction 
(online) 


X XX 

X X X X X 


XX  XX 

XXX  XX 


X X X X X X 

X X X X X X X 


X X 

XXXX  x 


Transaction 


Message  B B B B B 

3 3 3 3 5 

4 6 6 6 0 

2 0 12  0 


BBBBBBBBC 
5 56669995 

00  00033  3 0 

1 2 0 1 2 0 1 3 0 


c C C C C D D 

5 5 5 3 5 1 1 

ooooioo 

6 7 8 9002 


D D D D D D D 
1111111 
0 4 4 4 5 5 5 
3 0 2 3 0 3 4 


Services  estimate 
Initial  (batch 
Update  and  correction 
(online) 

Services 
Initial  (batch) 

Update  and  correction 
(online) 

Su££lies 
Initial  (batch) 

Update  and  correction 
(online) 


XXX 

XXX 


X X X X X 
XXXX 


XXX 

XXX 


XXXX  x 


XXX 

X X X 


X X X X X 
XXXX 


XXX 

X x X 


XXXX  x 


X X X X x X 

X X X X X x X 


X X X X X X X 
X X 


X X X X X X X X X X X X 


Figure  2.9-12.  - Cost  Distribution  messages  by  transaction. 
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Inquiry  description 


Ti£e 


Input  data  elements 


Timing 


Response  data  elements 


Reservation  Accounts 
by  carrier  Identifier 
and  Carrier  Responsible 
Organization 


List 


Carrier  Identifier 
Carrier  Responsi- 
ble Organization 


Overnight  Method  of  Authority 
Program  Year 
Fund  Source 

Responsible  Organization 
Primary  Work  Code  (five  digits) 
or  Object  Class 
Carrier  Identifier 
Carrier  Responsible  Organization 
Reservation  PWA  receipts 
Reservation  PWA  issues 
Reservation  PWA  balance 


Figure  2.9-13.  - Cost  Distribution  inquiry  requirements. 
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1 .5 
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l , 

input  and  online  input  will  be  described  in  section  2.19.7. 
The  following  reports  are  included  in  that  section* 

{■: 

• Daily  Transaction  List  Distribution  of 

K 

; Services  Sectxon 

• Daily  Transaction  List  Distribution  of 

I Supplies  Section 

• External  Transaction  List  Distribution  of 
Services  Section 


• External  Transaction  List  Distribution  of 
Supplies  Section 


2 . 10  DISBURSEMENT  PROCESS 


The  Disbursement  process  includes  the  recording  of 
disbursements  for  all  contracts,  grants,  letters  of  credit, 
T-orders,  GBL's,  and  MILSTRIP/FEDSTRIP  items.  The  various 
transactions  included  in  the  process  are  input  by  the 
Commercial  Accounts  Unit. 

2.10.1  Update  Requirements 

2.10.1.1  Contract disbursement . The  contract 

disbursement  process  inputs  and  records  the  disbursement  for 
those  contracts  which  are  not  paid  under  a letter  of  credit. 
Payments  are  normally  made  and  the  disbursement  recorded 
upon  receipt  of  an  invoicing  document  from  the  contractor 
and  either  the  receipt  of  the  equipment  or  supplies  invoiced 
or  the  certification  of  the  invoicing  document  by  an 
authorized  contracting  officer.  The  disbursement  is 
normally  entered  at  the  contract  level  and  distributed  to 
the  various  PR's  associated  with  the  contract  according’  to 
the  oldest  PR  first  criteria. 

The  contract  disbursement  process  consists  of  a series 
of  disbursement  transactions,  an  adjustment  transaction,  an 
update  transaction,  a correction  transaction,  a reopening 
transaction,  and  a cancelled  check  transaction  defined  as 
follows: 


• Disbursement  - a transaction  that  records  the 
disbursement . 

• Adjustment  - a transaction  that  adjusts  commitment, 
obligation,  and  cost. 


• Update  - a transaction  that  updates  the 
disbursement.  The  transaction  must  have  been 
directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  disbursement,  the 
adjustment,  or  the  update  transaction. 

• Reopening  - a transaction  that  reopens  a contract 
that  was  closed  during  the  current  year. 

• Cancelled  check  ~ a transaction  that  records  the 
cancellation  of  a check  and  the  reversal  of  the 
original  disbursement. 

The  various  disbursement  transactions  are  defined  as 
follows : 


• Net  disbursement  - a transaction  that  records  a net 
disbursement,  which  is  defined  as  any  payment  that 
is  not  a deposit  on  containers,  a payment  by  others, 
or  a payment  on  reimbursable  orders. 

• Deposit  on  containers  - a transaction  that  records  a 
payment  for  a deposit  on  containers,  which  is 
defined  as  a payment  for  a deposit  on  a drum  or 
container.  The  deposit  on  containers  is  a special 
type  of  disbursement;  it  must  be  recorded  both  as  a 
deposit  on  containers  and  as  a disbursement. 

• Payment  by  others  - a transaction  that  records  a 
payment  by  others,  which  is  defined  as  a payment 
made  by  some  governmental  agency  other  than  JSC  but 
recorded  as  a JSC  disbursement  because  it  pertains 
to  JSC  activities.  These  payments  may  be  either  a 
foreign  payment  other  than  Canadian  which  is  made  by 
the  Treasury  Regional  Disbursing  Office  serving  the 
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foreign  country  or  a payment  made  by  NASA 
Headquarters  for  some  specific,  large  contracts. 
The  payment  by  others  is  a special  type  of 
disbursement;  it  must  be  recorded  both  as  a payment 
by  others  and  as  a disbursement. 

• Payment  on  reimbursable  orders  - a transaction  that 
records  a payment  on  a reimbursable  order,  which  is 
defined  as  a payment  on  a contract  for  which  JSC  is 
to  be  reimbursed  later  by  some  non-NASA  source.  The 
payment  on  reimbursable  orders  is  a special  type  of 
disbursement;  it  must  be  recorded  both  as  a payment 
on  reimbursable  orders  and  as  a disbursement. 

• Advance  established  - a transaction  that  records  an 
advance  payment,  which  is  defined  as  a payment  that 
is  actually  made  but  for  which  the  cost  and 
disbursement  cannot  be  recorded. 

• Advance  liquidated  - a transaction  that  records  the 
liquidation  of  an  advance.  The  advance  liquidated 
must  be  recorded  as  a disbursement. 

• Discount  - a transaction  that  records  a discount, 
which  is  defined  as  an  amount  invoiced  but  not  paid 
resulting  frcm  the  contractor  authorizing  reductions 
in  payments  for  prompt  payment  or  volume  purchasing 
and  those  conditions  being  satisfied.  When  a 
discount  is  taken,  the  discount  amount  must  be 
computed  manually  as  a percentage  of  the  amount 
invoiced.  The  amount  paid  is  the  amount  invoiced 
less  the  discount. 

• Withholding  - a transaction  that  records  a 
withholding,  which  is  defined  as  an  amount  invoiced 
but  not  paid  until  certain  contract  withholding 
conditions  are  satisfied.  When  these  conditions  are 
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can  be  released  and 


satisfied,  the  withholding 
payment  made  upon  receipt  of  a new  invoicing 
document.  When  a withholding  applies,  the 

withholding  amount  must  be  computed  manually.  The 

amount  paid  is  the  amount  invoiced  less  the 
withholding. 

A single  invoice  may  initiate  several  disbursement 
transactions.  One  situation  might  be  an  invoice  which  is 
totally  for  a net  disbursement;  a net  disbursement 

transaction  would  be  the  only  transaction  required.  A 
second  situation  might  be  an  invoice  which  is  totally  for  a 
payment  by  others;  a payment  by  others  transaction  would  be 
the  only  transaction  required.  A third  situation  might  be 
an  invoice  which  is  partially  for  a deposit  on  containers;  a 
deposit  on  containers  transaction  would  be  requried  for  the 
deposit  on  containers  amount,  and  a net  disbursement 
transaction  would  be  required  for  the  remainder  of  the 
amount  invoiced.  A fourth  situation  might  be  an  invoice 
which  is  totally  for  a net  disbursement  but  for  which  a 
discount  is  taken;  a discount  transaction  would  be  reguired 
for  the  discount  amount,  and  a net  disbursement  transaction 
would  be  reguired  for  the  remainder  of  the  amount  invoiced. 
Many  such  combinations  of  transactions  are  possible.  The 
transactions  for  any  single  invoice  may  be  input  at  the  same 
time;  however,  the  requirements  for  each  transaction  are 
discussed  separately. 

The  input,  processing,  and  output  requirements  for  the 
disbursement  transactions,  the  adjustment  transaction,  the 
update  transaction,  and  the  correction  transaction  are 
discussed  in  the  following  paragraphs.  The  requirements  for 


the  reopening  transaction  are  discussed  in  section  2.10.1.8. 
The  requirements  for  the  cancelled  check  transaction  are 
discussed  in  section  2.10.1.9. 

~ Figure  2.10-1  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
contract  disbursement  process.  Figure  2.10-2  defines  the 
template  required  for  input  of  these  data  elements. 

The  various  disbursement  transactions  are  specified  by 
the  entry  of  the  appropriate  disbursement  dollar  amounts; 
the  amounts  entered,  except  for  withholding  dollars,  must  be 
positive.  The  adjustment  transaction  is  specified  by  the 
entry  of  commitment/obligation  dollars  and/or  cost  dollars; 
the  amounts  entered  may  be  either  positive  or  negative. 
Figure  2.10-3  contains  a list  of  these  transactions  and  the 
amount  or  amounts  that  must  or  may  be  entered  for  each 
transaction.  The  update  transaction  is  specified  by  the 
update  indicator  and  the  entry  of  the  appropriate 
disbursement  dollar  amounts;  the  amounts  entered  may  be 
either  positive  or  negative.  The  correction  transaction  is 
specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered. 

Several  transactions  may  be  entered  at  the  same  time. 
A net  disbursement  transaction  may  be  entered  alone  or  with 
any  of  the  other  disbursement  transactions.  Only  one  of  (1) 
the  deposit  on  containers  transaction,  (2}  the  payment  by 
others  transaction,  or  (3)  the  payment  on  reimbursable 
orders  transaction  may  be  entered  at  one  time.  A discount 
transaction  must  be  entered  with  one  of  the  transactions 
discussed  above;  it  may  not  be  entered  alone.  A withholding 
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Data 

element 

Element 

reauired 

Source 

Error 

tipe 

Innut/Edit  requirements 

code 

'As  of1 
Date 

Opt ional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  cate  other  than  the  _ 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Contract 

number 

Yes 

Invoicing 

document 

Fatal 

Input  for  all  disbursement,  adjustment,  update,  and 
correction  transactions.  Positions  1 and  2 must  be 
a valid  contract  prefix. 

B360 

B361 

Contract 

Schedule 

Number 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  ind  cor- 
rection transactions  when  distribution  is  to  be  l1®1- 
ted  to  a specific  Contract  Schedule  Number.  Must  be 
alphabetic.  Must  not  be  input  when  the  Purchase  Re- 
quest Number  and  Suffix  are  entered. 

B3  8*0 
B3  8 1 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

input  for  all  disbursement  and  update  transactions 
except  the  withholding  and  for  the  correction  trans- 
action when  it  is  to  be  corrected.  Position  1 must 
be  J , and  positions  2 through  4 must  be  numeric, 
or  all  must  be  numeric. 

B930 

-B931 

Net 

disbursement 
d oil ars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
ther®  is  a net  disbursement  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  For  a dis- 
bursement transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction, 
must  be  numeric  and  not  equal  to  0. 

B701 

B702 

B703 

Di scount 
dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  a discount  and  for  the  correction  transac- 
tion when  it  is  to  be  corrected.  For  a disbursement 
transaction,  must  be  numeric  and  greater  than  0.  For 
an  update  or  correction  transaction,  must  be  numeric 
and  not  equal  to  0. 

B711 

B712 

B713 

Withholding 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  a withholding  or  a withholding  released  and 
for  the  correction  transaction  when  it  is  to  be  cor- 
rected. Must  be  numeric  and  not  equal  to  0. 

B721 

B722 

Deposit  on 
containers 
dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  a deposit  on  containers  and  for  the  cor- 
rection transaction  whur  it  i.»  to  be  corrected.  For 
a disbursement  transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction,  must 
be  numeric  and  not  egual  to  0. 

B731 

B732 

B733 

Payment  by 

others 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  a payment  by  others  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  For  a dis- 
bursement transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction. 

B741 

B742 

B743 

must  be  numeric  and  not  equal  to  0. 


Figure  2.10-1. 


- Contract  Disbursement  input  and  edit  requirements. 


Data 

element 


Discount 

override 


Advance 

established 

dollars 


Advance 

liquidated 

dollars 


Commitment/ 

Obligation 

Dollars 


Cost  Dollars 


Purchase 

Request 

Number 


Suffix 


Reopening 


Cancelled 
S->  <£heck 


Element 

required 

Source 

Error 

t££e 

Innut/Edit  requirements 

Error 

code 

Conditional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  discount 
must  not  reduce  the  commitment,  obligation,  and 
cost.  Must  not  be  input  unless  discount  dollars  are 
input. 

B840 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  an  advance  established  and  for  the  correc- 
tion transaction  when  it  is  to  be  corrected.  For  a 
disbursement  transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction, 
must  be  numeric  and  not  equal  to  0. 

B751 

B752 

B753 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  an  advance  established  and  for  the  correc- 
tion transaction  when  it  is  to  be  corrected.  For  a 
disbursement  transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction, 
must  be  numeric  and  not  equal  to  0. 

B761 

B762 

B763 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  ad- 
justment is  to  be  made  to  the  commitment  and  ob- 
ligation and  for  the  correction  transaction  when 
it  is  to  be  corrected.  Must  be  numeric  and  not 
equal  to  0.  Must  have  the  same  sign  as  cost 
dollars. 

B651 

B652 

B656 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  ad- 
justment is  to  be  made  to  the  cost  and  for  the 
correction  transaction  when  it  is  to  be  corrected. 
Must  be  numeric  and  not  equal  to  0.  Must  have  the 
same  sign  as  commitment/obligation  dollars. 

B631 

B632 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  cor- 
rection transactions  when  the  transaction  is  entered 
at  the  PR  level.  Positions  1 through  8 must  be  nu- 
meric. Position  9 must  be  alphabetic  or  blank. 

B301 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  cor- 
rection transactions  when  the  transaction  is  entered  at 
the  PR  level  and  the  suffix  is  other  than  the  base 
Suffix.  Must  be  numeric. 

B311 

No 

None 

None 

Must  not  be  input. 

None 

No 

None 

None 

Must  not  be  input. 

None 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  transaction 
and  the  correction  transaction  must  not  be  specified. 

B062 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the  trans- 
action is  a correction.  Both  the  update  transaction 
and  the  correction  transaction  must  not  be  specified. 

B062 

Figure  2.10-1.  - Contract  Disbursement  input  and  edit  requirements  (concluded). 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

****TEMPLATE  NO.  Ml  - CONTRACT  DISBURSEMENT 

CONTRACT  NO.  CONTRACT  SCHEDULE  _ VOUCHER  NO. 

NET  DISBURSEMENT  $ , , • ± DISCOUNT  * , , ._ 

WITHHOLDING  $ , , . ± DEPOSIT  ON  CONTAINERS  $ 

PAYMENT  BY  OTHERS  $ , , . ± DISCOUNT  OVERRIDE  _ 

ADVANCE  ESTABLISHED  $ , , . + ADVANCE  LIQUIDATED  $ 

ADJUSTMENT:  C/O  $ , , . ± COST  * , , . ± 

PR  LEVEL  ENTRY:  PURCHASE  REQUEST  NO.  SUFFIX  

REOPENING  _ CANCELLED  CHECK  _ 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


Figure  2.10-2.  - Contract  Disbursement  template. 
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Deposit  on  containers 

Payment  by  others 

Payment  on  reimbursable  orders 

Advance  established 

Advance  liquidated 

Discount 
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Ad 


Net  disbursement  dollars 
Deposit  on  containers  dollars 
Payment  by  others  dollars 
Net  disbursement  dollars 
Advance  established  dollars 
Advance  liquidated  dollars 
Discount  dollars 
Withholding  dollars 

Commit ment/Obligat ion  dollars 
Cost  dollars 


Figure  2.10-3.  - Contract  disbursement  and  adjustment  transactions 


transaction  may  be  entered  alone  or  with  any  of  the  other 
disbursement  transactions.  An  advance  transaction  may  be 
entered  alone  or  with  any  of  the  other  disbursement 
transactions;  however,  only  one  of  the  two  transactions  may 
be  entered  at  one  time.  An  adjustment  transaction  may  be 
entered  alone  or  with  any  of  the  disbursement  transactions. 
Both  an  update  transaction  and  a correction  transaction  may 
be  entered  at  the  same  time. 

Processing  - Each  of  the  transactions  in  the  contract 
disbursement  process,  whether  it  is  a disbursement, 
adjustment,  update,  or  correction  transaction,  may  be 
entered  either  at  the  contract  level  or  at  the  PR  level.  If 
the  transaction  is  entered  at  the  contract  level,  the  system 
must  select  a PR  according  to  the  oldest  PR  first  criteria. 
If  the  transaction  is  entered  at  the  PR  level,  the  PR  is  the 
PR  specified  on  the  template.  The  contract  record  to  be 
updated  is  defined  by  the  contract  number  entered  on  the 
template  and  the  performance  record  by  the  PR  number  and 
Suffix  entered  on  the  template  or  selected  by  the  system. 
For  the  transactions  in  the  contract  disbursement  process, 
both  records  must  exist  and  be  open. 

When  the  transaction  is  entered  at  the  contract  level, 
the  amounts  from  the  template  must  be  distributed  to  the 
various  PR's  associated  with  the  contract  according  to  the 
oldest  PR  first  criteria.  Within  this  context,  each  amount 
must  be  distributed  according  to  its  own  rules.  For 
example,  the  disbursement  must  be  distributed  according  to 
the  following  rules. 
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• The  distribution  of  the  disbursement  must  follow  the 
distribution  of  the  cost  and,  within  that,  must  be 
to  the  oldest  PR’s  first. 

• The  age  of  the  PR's  is  defined  by  the  digits  of  the 
PR  number;  specifically,  digits  1 and  2 of  the  year, 
digits  3 through  5 of  the  Julian  date,  digits  6 
through  8 of  the  sequence  number  within  the  Julian 
date,  and  digit  9 of  the  amendment  number. 

When  a contract  schedule  is  entered,  the  distribution  is 
restricted  to  PR's  with  the  schedule.  The  specific 
transaction  requirements  are  discussed  by  transaction  in 
the  following  paragraphs. 

tret  Disbursement 


The  net  disbursement  transaction  inputs  and  records  a 
net  disbursement.  Each  transaction  must  update  a contract 
record  and  a performance  record. 

If  the  transaction  is  entered  at  the  contract  level, 
the  disbursement  from  the  template  must  update  the 
disbursement  from  the  contract  record.  A cost  increment 
will  be  required  if  the  updated  disbursement  plus  the 
withholding  exceeds  the  cost.  The  updated  disbursement  plus 
the  withholding  must  not  exceed  the  obligation.  The 
disbursement  and  any  cost  increment  must  be  distributed  to 
the  PR's  with  the  oldest  PR  first.  The  disbursement  must  be 
distributed,  first,  to  the  costed  PR's  up  to  the  cost; 
second,  to  the  costed  PR's  up  to  the  obligation  less  the 
withholding;  and,  third,  to  the  uncosted  PR's  up  to  the 
obligation.  The  cost  increment  must  be  distributed  to  each 
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PR  such  that  the  cost  for  that  PR  is  not  less  than  the 
disbursement  plus  the  withholding. 

Xf  a contract  schedule  is  entered,  the  disbursement 
from  the  template  must  still  update  the  disbursement  from 
the  contract  record,  but  the  rest  of  the  processing  must  be 
restricted  to  the  schedule.  A cost  increment  will  be 
required  if  the  updated  disbursement  for  the  schedule 
exceeds  the  cost  for  the  schedule.  The  updated  disbursement 
plus  the  withholding  must  not  exceed  the  obligation.  The 
disbursement  and  any  cost  increment  must  be  disbributed  only 
to  PR’s  with  the  schedule.  Any  cost  increment  must  update 
the  cost  from  the  contract  record. 

If  the  transaction  is  entered  at  the  PR  level,  the 
disbursement  from  the  template  must  still  update  the 
disbursement  from  the  contract  record,  but  the  rest  of  the 
processing  must  be  restricted  to  the  PR.  The  disbursement 
from  the  template  must  be  applied  to  the  PR.  A cost 
increment  will  be  required  if  the  updated  disbursement  from 
the  performance  record  exceeds  the  cost  from  the  performance 
record.  The  updated  disbursement  plus  the  withholding  must 
not  exceed  the  obligation.  Any  cost  increment  must  update 
the  cost  from  the  contract  record. 

Deposit  on  Containers 

The  deposit  on  containers  transaction  inputs  and 
records  a deposit  on  containers.  Each  transaction  must 
update  a contract  record  and  a performance  record.  The 
deposit  on  containers  must  be  recorded  both  as  a deposit  on 
containers  and  as  a disbursement. 
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If  the  transaction  is  entered  at  the  contract  level, 
the  deposit  on  containers  from  the  template  must  update  the 
deposit  on  containers  and  the  disbursement  from  the  contract 
record,  A cost  increment  will  be  required  for  the  deposit 
on  containers.  The  updated  disbursement  plus  the 
withholding  must  not  exceed  the  obligation.  The  deposit  on 
containers  must  be  distributed  as  a disbursement  like  the 
disbursement  in  the  net  disbursement  transaction  and  as  a 
deposit  on  containers  in  the  same  proportions  as  the 
disbursement.  Any  cost  increment  must  be  distributed  like 
the  cost  increment  in  the  net  disbursement  transaction. 

Payment  by  Others 

The  payment  by  others  transaction  inputs  and  records  a 
payment  by  others.  Each  transaction  must  update  a contract 
record  and  a performance  record.  The  payment  by  others  must 
be  recorded  both  as  a payment  by  others  and  as  a 
disbursement. 


If  the  transaction  is  entered  at  the  contract  level, 
the  payment  by  others  from  the  template  must  update  the 
payment  by  others  and  the  disbursement  from  the  contract 
record.  A cost  increment  will  be  required  if  the  updated 
disbursement  plus  the  withholding  exceeds  the  cost.  The 
updated  disbursement  plus  the  withholding  must  not  exceed 
the  obligation.  The  payment  by  others  must  be  distributed 
as  a disbursement  like  the  disbursement  in  the  net 
disbursement  transaction  and  as  a payment  by  others  in  the 
same  amounts  as  the  disbursement.  Any  cost  increment  must 
be  distributed  like  the  cost  increment  in  the  net 
disbursement,  transaction . 

■'•'M'  r- 
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Payment  on  Reimbursable  Orders 

The  payment  on  the  reimbursable  orders  transaction 
inputs  and  records  a payment  on  a reimbursable  order.  Each 
transaction  must  update  a contract  record  and  a performance 
record.  Payments  on  reimbursable  orders  are  not 
specifically  identified  as  such  on  the  template;  the  payment 
is  input  as  a net  disbursement.  However,  the  payment  on 
reimbursable  orders  must  still  be  recorded  both  as  a payment 
on  reimbursable  orders  and  as  a disbursement. 

If  the  transaction  is  entered  at  the  contract  level, 
the  disbursement  from  the  template  must  update  the 
disbursement  from  the  contract  record.  A cost  increment 
will  be  required  if  the  updated  disbursement  plus  the 
withholding  exceeds  the  cost.  The  updated  disbursement  plus 
the  withholding  must  not  exceed  the  obligation.  The 
disbursement  must  be  distributed  like  the  disbursement  in 
the  net  disbursement  transaction.  Any  cost  increment  must 
be  distributed  like  the  cost  increment  in  the  net 
disbursement  transaction.  If  the  PR  to  which  the 
disbursement  is  distributed  has  a reimbursable  MA,  the 
disbursement  is  a payment  on  reimbursable  orders.  The 
disbursement  must  then  update  the  payment  on  reimbursab^fe 
orders  from  the  contract  record. 

Advance  Established 

The  advance  established  transaction  inputs  and  records 
the  establishment  of  an  advance.  Each  transaction  must 
update  a contract  record  and  a performance  record. 


If  the  transaction  is  entered  at  the  contract  level* 
the  advance  established  from  the  template  must  update  the 
advance  established  from  the  contract  record.  The  updated 
advance  established  less  the  advance  liquidated  plus  the 
disbursement  plus  the  withholding  must  not  exceed  the 
withholding.  The  advance  established  must  be  distributed 
like  the  disbursement  in  the  net  disbursement  transaction. 

Advance  Liguida;1  d 

The  advance  liquidated  transaction  inputs  and  records 
the  liquidation  of  the  advance  and  the  recording  of  the 
disbursement.  Each  transaction  must  update  a contract 
record  and  a performance  record. 

If  the  transaction  is  entered  at  the  contract  level, 
the  advance  liquidated  from  the  template  must  update  the 
advance  liquidated  and  the  disbursement  from  the  contract 
record.  A cost  increment  will  be  required  if  the  updated 
disbursement  plus  the  withholding  exceeds  the  cost.  The 
updated  advance  liquidated  must  not  exceed  the  advance 
established.  The  advance  liquidated  must  be  distributed  as 
a disbursement  like  the  disbursement  in  the  net  disbursement 
transaction  and  as  an  advance  liquidated  in  the  same  amounts 
as  the  disbursement.  Any  cost  increment  must  be  distributed 
like  the  cost  increment  in  the  net  disbursement  transaction. 

Discount 

The  discount  transaction  inputs  and  records  a discount. 
Each  transaction  must  update  a contract  record  and  a 
performance  record.  The  discount  transaction  must  be 
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entered  with  another  disbursement  transaction;  the  discount 
transaction  must  be  processed  first. 

If  the  transaction  is  entered  at  the  contract  level, 
the  discount  from  the  template  must  update  the  discount  from 
the  contract  record.  If  the  discount  override  is  not 


specified. 

the 

discount 

must 

reduce  the 

obligation.  A 

reduction 

in 

the  cost 

will 

be 

reguired 

if  the  updated 

obligation 

is 

less  than 
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Neither  the  updated 

obligation 

nor  the  updated 

cost 

may  be 

less  than  the 

disbursement  plus  the  withholding.  * The  discount,  the 
reduction  in  the  obligation,  and  any  reduction  in  the  cost 
must  be  distributed  to  the  PR's  with  the  oldest  PR  first. 
The  reduction  in  the  obligation  must  be  distributed,  first, 
to  the  costed  PR's  down  to  the  cost;  second,  to  the  costed 
PR's  down  to  the  disbursement  plus  the  withholding;  and, 
third,  to  the  uncosted  PR's  down  to  the  disbursement.  The 
discount  must  be  distributed  in  the  same  amounts  as  the 
reduction  in  the  obligation.  The  reduction  in  the  cost  must 
be  distributed  to  each  PR  such  that  the  cost  for  that  PR  is 
not  less  than  the  disbursement  plus  the  withholding  nor 
greater  than  the  obligation.  The  commitment  must  be  reduced 
for  each  PR  for  which  the  obligation  is  reduced.  The  funds 
must  be  returned  to  the  PWA  account  specified  by  the 
accounting  information  of  the  performance  record.  The 
issues  of  the  PWA  account  must  be  sufficient. 

For  PR's  funded  from  the  supply  carrier  account,  the 
system  must  generate  cost  distribution  transactions  to 
adjust  the  supply  carrier  account  and  appropriate 
Conventional  PWA  account  for  the  amount  of  the  discount. 
The  transactions  must  increase  the  issues  of  the  Carrier 


account  and  must  reduce  the  issues  of  the  Conventional 
account.  Both  the  Carrier  account  and  the  Conventional 
account  must  exist.  The  issues  of  the  Conventional  account 
must  not  be  reduced  below  0.  The  Carrier  account  to  be 
updated  is  defined  by  HA , PY,  FS,  RO,  and  the  first  five 
digits  of  the  PWC  from  the  performance  record.  The 
Conventional  PWA  account  is  defined  by  MA,  PY,  FS,  RO,  and  a 
constant  five-digit  PWC  if  FS  is  4 or  above;  by  MA,  PY,  FS, 
RO,  and  Object  Class  if  FS  is  3 and  the  PY  is  the  current 
year;  and  by  MA,  PY,  FS,  and  RO  if  FS  is  3 and  the  PY  is  a 
prior  year. 

Withholding 

The  withholding  transaction  inputs  and  records  a 
withholding.  Each  transaction  must  update  a contract  record 
and  a performance  record.  If  a withholding  transaction  is 
entered  with  another  disbursement  transaction,  the 
withholding  transaction  must  be  processed  first. 

If  the  transaction  is  entered  at  the  contract  level, 
the  withholding  from  the  template  must  update  the 
withholding  from  the  contract  record.  A cost  increment  will 
be  required  for  the  withholding.  The  updated  withholding 
plus  the  disbursement  must  not  exceed  the  obligation.  If 
the  updated  cost  exceeds  the  obligation,  the  excess  cost 
must  be  reversed.  The  net  cost  increment  will  be  the  cost 
increment  resulting  from  the  withholding  less  the  cost 
j^gvpi^sed.  The  withholding  and  the  net  cost  increment  must 
be  distributed  to  the  PR's  with  the  oldest  PR  first.  The 
withholding  must  be  distributed  to  each  PR  such  that  the 
disbursement  plus  the  withholding  for  that  PR  is  not  greater 


than  the  obligation.  The  net  cost  increment  must  be 
distributed  to  each  PR  such  that  the  cost  for  that  PR  is  not 
less  than  the  disbursement  plus  the  withholding  and  not 
greater  than  the  obligation- 

The  release  of  withholding  is  indicated  by  a negative 
withholding.  The  withholding  from  the  template  must  reduce 
the  withholding  and  the  cost  from  the  contract  record,  but 
must  not  reduce  either  below  . 0.  The  reduction  in 
withholding  and  the  reduction  in  cost  must  be  distributed  to 
the  various  PR's.  The  distribution  for  the  negative 
withholding  must  be  the  reverse  of  that  for  the  positive 
withholding. 


Excluded  Object  Classes 

A more  complicated  type  of  disbursement  is  one  that  has 
excluded  object  classes  among  the  various  PR's.  PR's  with 
excluded  object  classes  must  be  totally  excluded  from  the 
processing  of  disbursements  entered  at  the  contract  level; 
transactions  for  disbursements  to  these  PR's  must  be  entered 
at  the  PR  level. 

If  the  transaction  is  entered  at  the  contract  level  and 
excluded  object  classes  exist  among  the  various  PR's,  the 
disbursement  from  the  template  must  still  update  the 
disbursement  from  the  contract  record.  A cost  increment 
will  be  reguired  if  the  updated  disbursement  plus  the 
withholding  exceeds  the  cost  for  nonexcluded  object  classes. 
The  updated  disbursement  plus  the  withholding  must  not 
exceed  the  obligation  for  nonexcluded  object  classes.  The 
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disbursement  and  any  cost  increment  must  be  distributed  only 
to  PR's  with  nonexcluded  object  classes. 

Each  of  the  disbursement  transactions  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

Adjustment 

The  adjustment  transaction  inputs  and  records  changes 
to  the  commitment,  obligation,  and  cost.  An  adjustment  to 
the  commitment  and  obligation  might  be  the  deobligation  of 
excess  funds.  An  adjustment  to  the  cost  might  be  the 
shifting  of  the  cost  from  one  PR  associated  with  the 
contract  to  another.  Each  transaction  must  update  a 
contract  record  and  a performance  record.  Both  records  must 
exist  and  be  open. 

The  first  adjustment  transaction  is  an  adjustment  to 
the  commitment  and  obligation  only.  The 
commitment/obligation  from  the  template  must  update  the 
obligation  from  the  contract  record.  A reduction  in  the 
cost  will  be  required  if  the  updated  obligation  is  less  than 
the  cost.  Neither  the  updated  obligation  nor  the  updated 
cost  may  be  less  than  the  disbursement  plus  the  withholding. 
An  increase  in  the  obligation  must  be  applied  to  the  newest 
PR;  a reduction  must  be  distributed  to  the  PR's  with  the 
newest  PR  first.  The  commitment  must  be  increased  or 
reduced  for  each  PR  for  which  the  obligation  is  increased  or 
reduced.  The  funds  must  be  obtained  from  or  returned  to  the 
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PWA  account  or  accounts  specified  by  the  accounting 
information  of  the  performance  record  or  records.  Any 
increase  in  the  commitment  must  not  exceed  the 
preestablished  limits.  The  balance  or  the  issues  of  the  PWA 
account  must  be  sufficient. 

The  second  adjustment  transaction  is  an  adjustment  to 
commitment,  obligation,  and  cost.  The  commitment/obligation 
and  the  cost  from  the  template-  must  update  the  obligation 
and  the  cost  from  the  contract  record.  Neither  the  updated 
obligation  nor  the  updated  cost  may  be  less  than  the 
disbursement  plus  the  withholding;  the  updated  cost  must  not 
be  greater  than  the  updated  obligation.  An  increase  in  the 
obligation  and  the  cost  must  be  applied  to  the  newest  PR;  a 
reduction  must  be  distributed  to  the  PR's  with  the  newest  PR 
first.  The  commitment  must  be  increased  or  reduced  for  each 
PR  for  which  the  obligation  is  increased  or  reduced.  The 
funds  must  be  obtained  from  or  returned  to  the  appropriate 

PWA  account. 

The  third  adjustment  transaction  is  an  adjustment  to 
the  cost  only.  The  cost  from  the  template  must  update  the 
cost  from  the  contract  record.  The  updated  cost  must  not  be 
greater  than  the  obligation  or  less  than  the  disbursement 
plus  the  withholding.  An  increase  in  the  cost  must  be 
applied  to  the  newest  PR;  a reduction  must  be  distributed  to 
the  PR*s  with  the  newest  PR  first. 


The  adjustment  transaction  may  be  entered  at  either  the 
contract  level  or  the  PR  level.  The  processing  requirements 
for  the  transaction  entered  with  a contract  schedule  or 
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entered  at  the  PR  level  correspond  to  those  for  the 
disbursement  transactions. 

U pdate  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Contract  records  and  performance 
records  must  be  updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that,  in  all 
cases,  the  amounts  entered  may  be  either  positive  or 
negative.  Amounts  from  the  contract  and  performance  records 
must  be  increased  or  reduced.  The  normal  processing  edits 
must  be  satisfied;  in  addition,  a negative  update  or 
correction  must  not  reduce  any  of  the  amounts  from  any  of 
the  records  below  0.  For  the  contract  disbursement  process, 
the  dollar  data  elements  are  net  disbursement  dollars, 
discount  dollars,  withholding  dollars,  deposit  on  containers 
dollars,  payment  by  others  dollars,  advance  established 
dollars,  advance  liquidated  dollars  for  the  update 
transaction,  and  net  disbursement  dollars,  discount  dollars, 
withholding  dollars,  deposit  on  containers  dollars,  payment 
by  others  dollars,  advance  established  dollars,  advance 
liquidated  dollars,  commitment/obligation  dollars,  and  cost 
dollars  for  the  correction  transaction.  The  processing 
requirements  for  the  correction  of  information  data  elements 
specify  that  the  new  value  of  the  element  be  overlaid  on  the 
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old.  The  only  information  data  element  is  the  voucher 
number.  If  any  of  the  control  data  elements  are  entered 
incorrectly,  the  transaction  must  be  reversed  and  a new 
transaction  entered.  The  control  data  elements  are  the 
contract  number,  contract  schedule,  discount  override,  and 
the  PR  Number  and  Suffix. 

Any  cost  increments  made  automatically  by  the  system, 
when  the  disbursement  plus  the  withholding  is  greater  than 
the  cost,  cannot  be  corrected  automatically  by  the  system. 
The  updates  or  corrections  must  be  . made  manually  by  a 
separate  transaction. 

In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

The  update  and  correction  transactions  for  the  update 
or  correction  of  dollar  data  elements  or  control  data 
elements  may  be  entered  at  either  the  contract  level  or  the 
PR  level.  The  processing  reguirements  for  the  transaction 
entered  with  a contract  schedule  or  entered  at  the  PR  level 
correspond  to  those  for  the  disbursement  transactions.  The 
correction  transaction  for  the  correction  of  information 
data  elements  should  be  entered  only  at  the  PR  level. 

To  satisfy  audit  trail  reguirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 
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Output  - Section  2 . 10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  contract 
disbursement  process. 

2.10.1.2  Grant  disbursement.  The  grant  disbursement 
process  inputs  and  records  the  disbursement  for  those  grants 
which  are  not  paid  under  a letter  of  credit.  Payments  are 
normally  made  and  the  disbursement  recorded  quarterly  upon 
receipt  of  a Grantee  Quarterly  Cash  Requirement  Report  (NASA 
Form  1031) . The  disbursement  is  normally  entered  at  the 
contract  level  and  distributed  to  the  various  PR's 
associated  with  the  grant  according  to  the  oldest  PR  first 
criteria. 

In  addition  to  the  disbursement,  an  advance  amount  must 
be  input  and  recorded.  Each  quarter  the  grantee  reports  the 
amount  of  cash  that  will  be  required  in  the  next  quarter  and 
the  amount  that  has  been  spent  in  the  current  quarter. 
Payment  must  be  made  and  an  advance  established  for  the  next 
quarter's  requirements;  the  disbursement  must  be  recorded 
and  the  advance  liquidated  for  the  current  quarter's 
expenditures. 

The  grant  disbursement  process  consists  of  a 
disbursement  transaction,  an  adjustment  transaction,  an 
update  transaction,  a correction  transaction,  a reopening 
transaction,  and  a cancelled  check  transaction  defined  as 
follows: 


• Disbursement  - a transaction  that  records  the 
disbursement  and  the  advance. 


. Adjustment  - a transaction  that  adjusts  the 

commitment,  obligation,  and  cost. 

. update  - a transaction  that  updates  the  disbursement 
and  the  advance.  The  transaction  most  have  been 
directed  by  written  documentation. 

. correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  disbursement,  the 
adjustment,  or  the  update  transaction. 

. Deepening  - a transaction  that  reopens  a grant  that 

was  closed  during  the  current  year. 

• cancelled  check  - a transaction  that  records  the 
cancellation  of  a check  and  the  reversal  of  the 
original  disbursement. 

The  input,  processing,  and  output  reguirements  for  the 
disbursement  transaction,  the  adjustment  transaction,  the 
update  transaction,  and  the  correction  transaction  are 
discussed  in  the  following  paragraphs.  The  reguirements  for 
the  reopening  transaction  are  discussed  in  section  2.10.1.8. 
The  requirements  for  the  cancelled  check  transaction  are 
discussed  in  section  2.10.1.9. 

input  - Figure  2.10-4  contains  a list  of  data  elements 
that  Inst  be  input  and  edits  that  must  be  performed  for  the 
grant  disbursement  process.  Figure  2.10-5  defines 
template  required  for  input  of  these  data  elements. 

The  disbursement  transaction  is  specified  by  the  entry 
of  advance  established  dollars  and/or  advance  liquidated 
dollars:  the  amounts  entered  must  be  positive.  The 

adjustment  transaction  is  specified  by  the  entry  o 
commitment/obligation  dollars:  the  amounts  entered  may 
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Data 

Element 

Error 

Error 

element 

required 

Source 

type 

Tnput/Edit  requirements 

code 

*As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B101 

Grant  number 

Yes 

User  supplied 

Fatal 

Input  for  all  disbursement,  adjustment,  update,  and 
correction  transactions.  Positions  1 and  2 must  be 
a valid  grant  prefix. 

BB00 

B801 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  Position  1 must  be  J , and  positions  2 
through  4 must  be  numeric,  of  all  must  be  numeric. 

B930 

B931 

Advance 

established 

dollars 

Conditional 

Form  1031 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  an  advance  established  and  for  the  correc- 
tion transaction  when  it  is  to  be  corrected.  For  a 
disbursement  transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction, 
must  be  numeric  and  not  equal  to  0. 

B751 

B752 

B753 

Advance 

liquidated 

dollars 

Conditional 

Form  1031 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  an  advance  liquidated  and  for  the  correc- 
tion transaction  when  it  is  to  be  corrected.  For 
a disbursement  transaction,  oust  be  numeric  and 
greater  than  0.  For  an  update  or  correction  trans- 
action, oust  be  numeric  and  not  equal  to  C. 

B761 

B762 

B763 

Commitment/ 

obligation 

Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjust- 
ment is  to  be  made  to  the  commitment  and  obligation 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  (Just  be  numeric  and  not  equal  to  0.  Oust 
have  the  same  sign  as  cost  dollars. 

B651 

B652 

5656 

Cost  Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjust- 
ment is  to  be  made  to  the  cost  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  Must  be 
numeric  and  not  egual  to  0.  Must  have  the  same  sign 
as  commitment/obligation  dollars. 

B631 

B632 

Purchase 

Request 

Humber 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  correc- 
tion transactions  when  the  transaction  is  entered  at 
the  PR  level.  Positions  1 through  8 must  be  numeric. 
Position  9 must  be  alphabetic  or  blank. 

B301 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  correc- 
tion transactions  when  the  transaction  is  entered  at 
at  the  PR  level  and  the  suffix  is  other  than  the  base 
Suffix.  Must  be  numeric. 

B3Q1 

Reopening 

No 

None 

None 

Must  not  be  input. 

None 

Cancelled 

check 

No 

None 

None 

Must  not  be  input. 

None 

Update 

Optional 

User  supplied 

Patal 

Transaction  modifier  indicating  that  the  transaction 
is  an  update.  Input  only  when  the  transaction  is  an 
update.  Both  the  update  transaction  and  the  correc- 
tion transaction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction  is 
a correction.  Both  the  update  transaction  and  the 
correction  transaction  must  not  be  specified. 

B062 

Figure  2.10-4.  - Grant  Disbursement  input  ana  edit  requirements. 


****IFNS  SEPTEMBER  30,  1974  AS  OF  / / 

****TEMPLATE  NO.  M2  - GRANT  DISBURSEMENT 

GRANT  NO.  VOUCHER  NO.  

ADVANCE  ESTABLISHED  $ , , . ± ADVANCE  LIQUIDATED  $ 

ADJUSTMENT:  C/O  $ , , . ± COST  $ , . ± 

PR  LEVEL  ENTRY:  PURCHASE  REQUEST  NO.  SUFFIX  

REOPENING  _ CANCELLED  CHECK 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION 


Figure  2.10-5.  - Grant  Disbursement  template. 
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either  positive  or  negative.  Figure  2.10-6  contains  a list 
of  these  transactions  and  the  amount  or  amounts  that  must  or 
may  be  entered  for  each  transaction.  The  update  transaction 
is  specified  by  the  update  indicator  and  the  entry  of 
advance  established  dollars  and/or  advance  liguidated 
dollars;  the  amounts  entered  may  be  either  positive  or 
negative.  The  correction  transaction  is  specified  by  the 
correction  indicator;  any  data  elements  that  are  incorrect 
may  be  entered.  fin  adjustment  transaction  may  be  entered 
alone  or  with  the  disbursement  transaction.  Both  an  update 
transaction  and  a correction  transaction  may  not  be  entered 
at  the  same  time. 


Processing  - Each  of  the  transactions  in  the  grant 
disbursement  process,  whether  it  is  a disbursement, 
adjustment,  update,  or  correction  transaction,  may  be 
entered  at  either  the  contract  level  or  the  PR  level.  If 
the  transaction  is  entered  at  the  contract  level,  the  system 
must  select  a PR  according  to  the  oldest  PR  first  criteria. 
If  the  transaction  is  entered  at  the  PR  level,  the  PR  is  the 
PR  specified  on  the  template.  The  contract  record  to  be 
updated  is  defined  by  the  grant  number  entered  on  the 
template  and  the  performance  record  by  the  PR  Number  and 
Suffix  entered  on  the  template  or  selected  by  the  system. 
For  the  transactions  in  the  grant  disbursement  process,  both 
records  must  exist  and  be  open.  The  specific  transaction 
requirements  are  discussed  by  transaction  in  the  following 
paragraphs. 
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Dollar  amounts 


Disbursement  Advance  established  dollars 

Advance  liquidated  dollars 

Adjustment  Commitment/Obligation  dollars 

Cost  dollars 


Figure  2.10-6.  - Grant  disbursement  and 
adjustment  transactions. 


Disbursement 


The  disbursement  transaction  inputs  and  records  the 
advance  established,  the  advance  liquidated,  and  the 
disbursement.  Each  transaction  must  update  a contract 
record  and  a performance  record. 

If  the  transaction  is  entered  at  the  contract  level, 
the  advance  established  from  the  template  must  update  the 
advance  established  from  the  contract  record,  and  the 
advance  liquidated  must  update  the  advance  liquidated  and 
the  disbursement.  A cost  increment  will  be  required  if  the 
updated  disbursement  exceeds  the  cost.  Neither  the  updated 
advance  established  nor  the  updated  disbursement  may  exceed 
the  obligation,  and  the  updated  advance  liquidated  must  not 
exceed  the  updated  advance  established.  The  disbursement, 
the  advance  established,  the  advance  liquidated,  and  any 
cost  increment  must  be  distributed  to  the  PR's  with  the 
oldest  PR  first.  The  advance  established  must  be 
distributed,  first,  to  the  costed  PR's  up  to  the  cost; 
second,  to  the  costed  PR's  up  to  the  obligation;  and,  third, 
to  the  uncosted  PR's  up  to  the  obligation.  The  disbursement 
and  the  advance  liquidated  must  be  distributed  to  the  PR's 
up  to  the  advance  established.  The  cost  increment  must  be 
distributed  to  each  PR  such  that  the  cost  for  that  PR  is  not 
less  than  the  disbursement. 

If  the  transaction  is  entered  at  the  PR  level,  the 
advance  established  and  the  advance  liquidated  from  the 
template  must  still  update  the  advance  established,  the 
advance  liquidated,  and  the  disbursement  from  the  contract 
record,  but  the  rest  of  the  processing  must  be  restricted  to 
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the  PR.  The  advance  established,-  the  advance  liquidated, 
and  the  disbursement  from  the  template  must  be  applied  to 
the  PR.  A cost  increment  will  be  required  if  the  updated 
disbursement  from  the  performance  record  exceeds  the  cost 
from  the  performance  record.  Neither  the  updated  advance 
established  nor  the  updated  advance  liquidated  may  exceed 
the  obligation,  and  the  updated  advance  liquidated  must  not 
exceed  the  updated  advance  established.  Any  cost  increment 
must  update  the  cost  from  the  contract  record. 

The  disbursement  transaction  must  update  the  voucher 
number.  The  voucher  number  from  the  template  must  be 
overlaid  on  the  voucher  number  from  the  performance  record. 
Only  the  voucher  number  of  the  last  transaction  affecting 
the  record  must  be  maintained. 

Adjustment 

The  adjustment  transaction  inputs  and  records  changes 
to  the  commitment,  obligation,  and  cost.  An  adjustment  to 
the  commitment  and  obligation  might  be  the  deobligation  of 
excess  funds.  An  adjustment  to  the  cost  might  be  the 
shifting  of  the  cost  from  one  PR  associated  with  the  grant 
to  another.  Each  transaction  must  update  a contract  record 
and  a performance  record.  Both  records  must  exist  and  be 
open . 


The  first  adjustment  transaction  is  an  adjustment  to 
the  commitment  and  obligation  only.  The 
commitment/obligation  from  the  template  must  update  the 
obligation  from  the  contract  record.  A reduction  in  the 
cost  will  be  required  if  the  updated  obligation  is  less  than 
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the  cost.  The  updated  obligation  must  not  be  less  than  the 
advance  established  or  the  disbursement,  and  the  updated 
cost  must  not  be  less  than  the  disbursement.  An  increase  in 
the  obligation  must  be  applied  to  the  newest  PR;  a reduction 
must  be  distributed  to  the  PR's  with  the  newest  PR  first. 
The  commitment  must  be  increased  or  reduced  for  each  PR  for 
which  the  obligation  is  increased  or  reduced.  The  funds 
must  be  obtained  from  or  returned  to  the  PWA  account  or 
accounts  specified  by  the  accounting  information  of  the 
performance  record  or  records.  Any  increase  in  the 
commitment  must  not  exceed  the  preestablished  limits.  The 
balance  or  the  issues  of  the  PWA  account  must  be  sufficient. 

The  second  adjustment  transaction  is  an  adjustment  to 
commitment,  obligation,  and  cost.  The  commitment/obligation 
and  the  cost  from  the  template  must  update  the  obligation 
and  the  cost  from  the  contract  record.  The  updated 
obligation  must  not  be  less  than  the  advance  established  or 
the  disbursement;  the  updated  cost  must  not  be  greater  than 
the  updated  obligation;  the  updated  cost  must  not  be  less 
than  the  disbursement.  An  increase  in  the  obligation  and 
the  cost  must  be  applied  to  the  newest  PR;  a reduction  must 
be  distributed  to  the  PR's  with  the  newest  PR  first.  The 
commitment  must  be  increased  or  reduced  for  each  PR  for 
which  the  obligation  is  increased  or  reduced.  The  funds 
must  be  obtained  from  or  returned  to  the  appropriate  PWA 
account. 

The  third  adjustment  transaction  is  an  adjustment  to 
the  cost  only.  The  cost  from  the  template  must  update  the 
cost  from  the  contract  record.  The  updated  cost  must  not  be 
greater  than  the  obligation  or  less  than  the  disbursement. 


An  increase  in  the  cost  must  be  applied  to  the  newest  PR;  a 
reduction  must  be  distributed  to  the  PR's  with  the  newest 
PR's  first. 

The  adjustment  transaction  may  be  entered  at  either  the 
contract  level  or  the  PR  level.  The  processing  requirements 
for  the  transaction  entered  at  the  PR  level  correspond  to 
those  for  the  disbursement  transaction. 

Update  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Contract  records  and  performance 
records  must  be  updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that,  in  all 
cases,  the  amounts  entered  may  be  either  positive  or 
negative.  Amounts  from  the  contract  and  performance  records 
must  be  increased  or  reduced.  The  normal  processing  edits 
must  be  satisfied;  in  addition,  a negative  update  or 
correction  must  not  reduce  any  amounts  from  any  of  the 
records  below  0.  For  the  grant  disbursement  process,  the 
dollar  data  elements  are  advance  established  dollars  and 
advance  liquidated  dollars  for  the  update  transaction,  and 
advance  established  dollars,  advance  liquidated  dollars, 
commitment/obligation  dollars,  and  cost  dollars  for  the 
correction  transaction.  The  processing  requirements  for  the 
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correction  of  information  data  elements  specify  that  the  new 
value  of  the  element  be  overlaid  on  the  old.  The  only 
information  data  element  is  the  voucher  number.  If  any  of 
the  control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  control  data  elements  are  the  grant  number  and  the  PR 
Number  and  Suffix. 

Any  cost  increments  made  automatically  by  the  system 
when  the  disbursement  was  greater  than  the  cost  cannot  be 
corrected  automatically  by  the  system.  The  updates  or 
corrections  must  be  made  manually  by  a separate  transaction. 

In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

The  update  and  correction  transactions  for  the  update 
or  correction  of  dollar  data  elements  or  control  data 
elements  may  be  entered  at  either  the  contract  level  or  the 
PR  level.  The  processing. requirements  for  the  transaction 
entered  at  the  PR  level  correspond  to  those  for  the 
disbursement  transaction.  The  correction  transaction  for 
the  correction  of  information  data  elements  should  be 
entered  only  at  the  PR  level. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 


* Ijr 
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Output  - section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  grant 
disbursement  process. 


2.10.1.3  Letter of  credit  disbursement.  The  letter 

of  credit  disbursement  process  inputs  and  records  the 
disbursement  for  those  contracts  and  grants  paid  under  a 
letter  of  credit.  The  disbursement  is  normally  recorded 
quarterly  upon  receipt  of  a Contractor's  Quarterly  Cash 
Requirement  Report  (NASA  Form  1031)  . The  disbursement  is 
normally  entered  at  the  contract  level  and  distributed  to 
the  various  PR's  associated  with  the  contract  or  grant 
according  to  the  oldest  PR  first  criteria. 

A letter  of  credit  is  established  primarily  for 
nonprofit  educational  and  research  organizations  which  have 
large  contracts  with  JSC.  These  organizations  are 
authorized  to  request  payment  from  a Federal  Reserve  Bank 
rather  than  directly  from  JSC.  The  payment  (withdrawal)  is 
limited  by  the  amount  of  the  letter  of  credit  issued  by  JSC. 
A Letter  of  Credit  (Standard  Form  1193)  is  issued  and  the 
issuance  recorded  upon  an  increase  in  the  obligation  of  a 
contract  or  grant  paid  under  a letter  of  credit. 
Withdrawals  are  recorded  upon  receipt  of  a Payment  Voucher 
on  Letter  of  Credit  (Form  TUS5401)  from  the  appropriate 
Federal  Reserve  Bank. 


A separate  transaction  must  be  input  to  record  the 
issuance  of  the  letter  of  credit,  the  withdrawal,  and  the 
disbursement.  The  requirements  for  each  of  these  processes 
are  discussed  in  the  following  sections. 
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2.10.1.3*1  Letter  of  credit  issuance:  The  letter  of 

credit  issuance  process  consists  of  an  issuance  transaction, 
an  update  transaction,  and  a correction  transaction  defined 
as  follows. 

• Issuance  - a transaction  that  records  an  issuance  of 
the  letter  of  credit. 

• Update  - a transaction  that  updates  the  issuance. 
The  transaction  must  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  issuance  or  the 
update  transaction. 

V 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.10-7  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
letter  of  credit  issuance  process.  Figure  2.10-8  defines 
the  template  required  for  input  of  these  data  elements. 

The  issuance  transaction  is  specified  by  the  entry  of 
issuance  dollars;  the  amount  entered  must  be  positive.  The 
update  transaction  is  specified  by  the  update  indicator  and 
the  entry  of  issuance  dollars;  the  amount  entered  may  be 
either  positive  or  negative.  The  correction  transaction  is 
specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Both  an  update 
transaction  and  a correction  transaction  may  not  be  entered 
at  the  same  time. 
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Data 

element 


Error  Error 

type  Input/Edit  requirements  code 

Fatal  Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Fatal  Input  for  all  issuance,  update,  and  correction  trans-  B810 

actions.  Digits  Y through  6 must  be  800072.  Digits  B811 
7 and  8 must  be  numeric. 

Fatal  Input  for  all  issuance,  update,  and  correction  trans-  B860 

actions.  Positions  1 and  2 must  be  a valid  contract  B861 

or  grant  prefix. 

Fatal  Input  for  issuance,  update,  and  correction  trans-  B380 

actions  when  distribution  is  to  be  limited  to  a B381 


specific  Contract  Schedule  Number.  Must  be  alpha- 
betic. Must  not  be  input  when  the  Contract/Grant 
Number  indicates  a grant.  Must  not  be  input  when 
the  Purchase  Request  Number  and  Suffix  are  entered 


Fatal  Input  for  all  issuance  and  update  transactions  and  B600 

for  the  correction  transaction  when  it  is  to  be  B601 

corrected.  For  an  issuance  transaction,  must  be  B602 

numeric  and  greater  than  0.  For  an  update  or  cor-  B604 

rection  transaction,  must  be  numeric  and  not  equal 
to  0 . 

Fatal  Input  for  all  issuance  and  update  transactions  and  B930 

for  the  correction  transaction  when  it  is  to  be  cor-  B931 
rected.  Position  1 must  be  J . Positions  2 through 
4 must  be  numeric. 

Fatal  Input  for  issuance,  update,  and  correction  trans-  B301 


actions  when  the  transaction  is  entered  at  the  PR 
level.  Positions  1 through  8 must  be  numeric. 

Position  9 must  be  alphabetic  or  blank. 

Fatal  Input  for  issuance,  update,  and  correction  trans-  B311 

actions  when  the  transaction  is  entered  at  the  PR 
level  and  the  suffix  is  other  than  the  base  Suffix. 

Must  be  numeric. 

Fatal  Transaction  modifier  indicating  that  the  transaction  B062 

is  an  update.  Input  only  when  the  transaction  is  an 
update.  Both  the  update  transaction  and  the  cor- 
rection transaction  must  not  be  specified. 

Fatal  Transaction  modifier  indicating  that  the  transaction  B062 

is  a correction.  Input  only  when  the  transaction 
is  a correction.  Both  the  update  transaction  and  the 
correction  transaction  must  not  be  specified. 


of  Credit  Issuance  input  and  edit  requirements. 


At-  > 


(p's 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / 

♦♦♦♦TEMPLATE  NO.  M3  - LETTER  OF  CREDIT  ISSUANCE 
LETTER  OF  CREDIT  NO.  

CONTRACT/GRANT  NO.  CONTRACT  SCHEDULE 

ISSUANCE  $ , , ± TOUCHER  NO. 

PR  LEVEL  ENTRY:  PURCHASE  REQUEST  NO.  SUFFIX 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION 


Figure  2.10-8.  - Letter  of  Credit  Issuance  template. 


Processing  - Each  of  the  transactions  in  the  letter  of 
credit  issuance  process,  whether  it  is  an  issuance,  update, 
or  correction  transaction,  may  be  entered  at  either  the 
contract  level  or  the  PR  level.  If  the  transaction  is 
entered  at  the  contract  level,  the  system  must  select  a PR 
according  to  the  oldest  PR  first  criteria.  If  the 
transaction  is  entered  at  the  PR  level,  the  PR  is  the  PR 
specified  on  the  template.  The  contract  record  to  be 
updated  is  defined  by  the  contract  or  grant  number  entered 
on  the  template  and  the  performance  record  by  the  PR  Number 
and  Suffix  entered  on  the  template  or  selected  by  the 
system.  For  the  issuance  transaction,  both  records  must 
exist  and  be  open.  The  specific  transaction  requirements 
are  discussed  by  transaction  in  the  following  paragraphs. 

Issuance 

The  issuance  transaction  inputs  and  records  an  issuance 
of  the  letter  of  credit.  Each  transaction  must  create  or 
update  a letter  of  credit  issuance  record,  create  or  update 
a letter  of  credit  control  record,  and  update  a contract 
record  and  a performance  record. 

For  the  issuance  transaction,  the  letter  of  credit 
issuance  record  may  or  may  not  already  exist.  If  the  record 
does  not  exist,  it  must  be  created.  The  issuance  amount 
from  the  template  must  update  the  issuance  amount  from  the 
record.  The  record  must  be  created  with  the  following  data 
elements: 

• Letter  of  credit  number 

• Program  Year 
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• Voucher  number 

• Issuance  dollar  amount 

The  record  is  defined  by  the  letter  of  credit  number  and  PY. 
The  letter  of  credit  number  is  entered  on  the  template,  and 
PY  is  obtained  from  the  performance  record. 

For  the  issuance  transaction,  the  letter  of  credit 
control  record  may  or  may  not  already  exist.  If  the  record 
does  not  exist,  it  must  be  created.  The  issuance  amount 
from  the  template  must  update  the  issuance  amount  from  the 
record. 

The  record  must  be  created  with  the  following  data 
elements : 

• Letter  of  credit  number 

• Voucher  number 

• Issuance  dollar  amount 

The  record  is  defined  by  the  letter  of  credit  number. 

If  the  transaction  is  entered  at  the  contract  level, 
the  issuance  amount  from  the  template  must  update  the 


issuance 

amount 

from 

the 

contract 

record . 

The  updated 

issuance 

amount 

must 

not 

exceed 

the  obligation.  The 

issuance 

amount 

must 

be 

distributed  to  the 

PR's  with  the 

oldest  PR 

first. 

The 

issuance  amount 

must  be 

distributed. 

first,  to  the  costed  PR's  up  to  the  cost;  second,  to  the 
costed  PR's  up  to  the  obligation;  and  third,  to  the  uncosted 
PR's  up  to  the  obligation. 
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If  a contract  schedule  is  entered,  the  issuance  amount 
from  the  template  must  still  update  the  issuance  amount  from 
the  contract  record,  but  the  rest  of  the  processing  must  be 
restricted  to  the  schedule.  The  updated  issuance  amount  for 
the  schedule  must  not  exceed  the  obligation  for  the 

schedule.  The  issuance  amount  must  be  distributed  only  to 

PR’s  with  the  schedule. 

If  the  transaction  is  entered  at  the  PR  level,  the 

issuance  amount  from  the  template  must  still  update  the 
issuance  amount  from  the  contract  record,  but  the  rest  of 
the  processing  must  be  restricted  to  the  PR.  The  issuance 
amount  must  be  applied  to  the  PR.  The  updated  issuance 

£ 

amount  from  the  performance  record  must  not  exceed  the 
obligation  from  the  performance  record. 

In  addition,  the  issuance  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 

be  overlaid  on  the  voucher  number  from  the  letter  of  credit 

i. 

control  record,  the  letter  of  credit  issuance  record,  and 

\ ■ 

the  performance  record.  Only  the  voucher  number  of  the  last 
transaction  affecting  the  records  must  be  maintained. 


Update  and  Correction 


The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Letter  of  credit  records, 
contract  records,  and  performance  records  must  be  updated  or 
corrected  appropriately. 


The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that  the  amount 
entered  may  be  either  positive  or  negative.  Amounts  from 
the  letter  of  credit  records,  contract  records,  and 
performance  records  must  be  increased  or  reduced.  The 
normal  processing  edits  must  be  satisfied;  in  addition,  a 
negative  update  or  correction  must  not  reduce  any  of  the 
amounts  from  any  of  the  records  below  0.  For  the  letter  of 
credit  issuance  process,  the  only  dollar  data  element  is 
issuance  dollars.  The  processing  requirements  for  the 
correction  of  information  data  elements  specify  that  the  new 
value  of  the  element  be  overlaid  on  the  old.  The 
information  data  elements  are  the  voucher  number.  If  any  of 
the  control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  control  data  elements  are  the  letter  of  credit  number, 
PY,  contract  number,  and  PR  Number  and  Suffix. 

In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  letter  of  credit 
control  record,  the  letter  of  credit  issuance  record,  and 
the  performance  record.  Only  the  voucher  number  of  the  last 
transaction  affecting  the  records  must  be  maintained. 

The  update  and  correction  transactions  for  the  update 
or  correction  of  dollar  data  elements  or  control  data 
elements  may  be  entered  at  either  the  contract  level  or  the 
PR  level.  The  processing  requirements  for  the  transaction 
entered  with  a contract  schedule  or  entered  at  the  PR  level 
correspond  to  those  for  the  issuance  transaction.  The 
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correction  transaction  for  the  correction  of  information 
data  elements  should  be  entered  only  at  the  PR  level. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  that  are  required  in  the  letter 
of  credit  issuance  process. 

2.10.1.3.2  Letter  of  credit  withdrawal:  The  letter  of 

credit  withdrawal  process  consists  of  a withdrawal 

transaction,  an  update  transaction,  and  a correction 

transaction  defined  as  follows: 

• Withdrawal  - a transaction  that  records  a withdrawal 
on  the  letter  of  credit. 

• Update  - a transaction  that  updates  the  withdrawal. 
The  transaction  must  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  withdrawal  or  the 
update  transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Injmt  - Figure  2.10-9  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
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Data 

element 


Element 

required 


Source 


Error 

tXE£ 


Error 

code 


*bs  of* 
Date 


Letter  of 

credit 

number 

Letter  of 
credit 
voucher 
number 


Serial 

number 


ro  Fithdrawal 

dollars 


Voucher 

number 


Update 


Correction 


Optional  User  supplied  Fatal 


Yes  Fora  TUS  5401  Fatal 

Conditional  Form  TUS  5401  Fatal 


Conditional  Form  TUS5401  Fatal 


Conditional  Form  TUS  5401  Fatal 


Conditional  User  supplied  Fatal 


Optional  User  supplied  Fatal 


Optional  User  supplied  Fatal 


Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  withdrawal,  update,  and  correction 
transactions.  Digits  1 through  6 must  be  800072. 
Digits  7 ana  8 must  be  numeric. 

Identification  number  of  the  letter  of  credit  with- 
drawal source  document.  Input  for  all  withdrawal 
and  update  transactions  and  for  the  correction  trans- 
action when  it  is  to  be  corrected.  Must  be  nuemric 
and  not  less  than  0. 

Identification  number  of  the  letter  of  credit  with- 
drawal source  document.  Input  for  all  withdrawal 
and  update  transactions  and  for  the  correction  trans- 
actions when  it  is  to  be  corrected.  Bust  be  numeric 
and  not  less  than  0. 

Input  for  all  withdrawal  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  For  a withdrawal  transaction,  must  be 
numeric  and  greater  than  0.  For  an  update  or  cor- 
rection transaction,  must  be  numeric  and  not  egual 
to  0 . 

Input  for  all  withdrawal  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected,  position  1 must  be  J . Positions  2 
through  4 must  be  numeric. 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  transaction 
and  the  correction  transaction  must  not  be  speci- 
fied. 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction 
is  a correction.  Both  the  update  transaction  and 
the  correction  transaction  must  not  be  specified. 


B 1 00 
B 1 0 1 


B810 
B81 1 


B820 

B821 

B822 


B830 
B83  1 
B832 


B600 

B601 

B602 

B604 


B930 

B931 


B062 


B062 


Figure  2.10-9. 


- Letter  of  Credit  Withdrawal  input  and  edit  requirements. 


letter  of  credit  withdrawal  process.  Figure  2.10-10  defines 
the  template  reguired  for  input  of  these  data  elements. 

The  withdrawal  transaction  is  specified  by  the  entry  of 
withdrawal  dollars;  the  amount  entered  must  be  positive. 
The  update  transaction  is  specified  by  the  update  indicator 
and  the  entry  of  withdrawal  dollars;  the  amount  entered  may 
be  either  positive  or  negative.  The  correction  transaction 
is  specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Both  an  update 
transaction  and  a correction  may  not  be  entered  at  the  same 
time. 


Processing  - The  specific  transaction  requirements  are 
discussed  by  transaction  in  the  following  paragraphs. 


Withdrawal 


The  withdrawal  transaction  inputs  and  records  a 
withdrawal  on  the  letter  of  credit.  Each  transaction  must 
update  a letter  of  credit  control  record. 

The  withdrawal  amount  from  the  template  must  update  the 
withdrawal  amount  from  the  letter  of  credit  control  record. 
The  letter  of  credit  control  record  is  defined  by  the  letter 
of  credit  number.  For  the  withdrawal  transaction,  the 
record  must  exist.  The  updated  withdrawal  amount  must  not 
exceed  the  issuance  amount. 

In  addition,  the  withdrawal  transaction  must  update  the 
letter  of  credit  voucher  number,  the  serial  number,  and  the 
voucher  number.  The  letter  of  credit  voucher  number 
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M\  > 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

**** TEMPLATE  MO.  M4  - LETTER  OF  CREDIT  WITHDRAWAL 

LETTER  OF  CREDIT  NO.  LETTER  OF  CREDIT  VOUCHER  NO. 

SERIAL  NUMBER  WITHDRAWAL  $ , .-„±  VOUCHER  NO. 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


/* 


Figure  2.10-10.  *-  Letter  of  Credit  Withdrawal  template. 


from  the  template  must  be  overlaid  on  the  letter  of  credit 
voucher  number  from  the  letter  of  credit  control  record;  the 
serial  number  from  the  template  must  be  overlaid  on  the 
serial  number  from  the  letter  of  credit  control  record;  and 
the  voucher  number  from  the  template  must  be  overlaid  on  the 
voucher  number  from  the  letter  of  credit  control  record. 
Only  the  letter  of  credit  voucher  number,  the  serial  number, 
and  the  voucher  number  of  the  last  transaction  affecting  the 
records  must  be  maintained. 

Update  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  The  letter  of  credit  control 
record  must  be  updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that  the  amount 
entered  may  be  either  positive  or  negative.  Amounts  from 
the  letter  of  credit  control  record  must  be  increased  or 
reduced  and  the  normal  processing  edits  must  be  satisfied. 
In  addition,  a negative  update  or  correction  must  not  reduce 
any  of  the  amounts  from  the  record  below  0.  For  the  letter 
of  credit  withdrawal  process,  the  only  dollar  data  element 
is  withdrawal  dollars.  The  processing  requirements  for  the 
correction  of  information  data  elements  specify  that  the  new 
value  of  the  element  be  overlaid  on  the  old.  The 
information  data  elements  are  the  letter  of  credit  voucher 
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number  and  the  voucher  number.  If  any  of  the  control  data 
elements  are  entered  incorrectly,  the  transaction  must  be 
reversed  and  a new  transaction  entered.  The  control  data 
element  is  the  letter  of  credit  number. 

In  addition,  the  update  transaction  must  update  the 
letter  of  credit  voucher  number,  the  serial  number,  and  the 
voucher  number.  The  letter  of  credit  voucher  number  from 
the  template  must  be  overlaid  on  the  letter  of  credit 
voucher  number  from  the  letter  of  credit  control  record;  the 
serial  number  from  the  template  must  be  overlaid  on  the 
serial  number  from  the  letter  of  credit  control  record;  and 
the  voucher  number  from  the  template  must  be  overlaid  on  the 
voucher  number  from  the  letter  of  credit  control  record. 
Only  the  letter  of  credit  voucher  number,  the  serial  number, 
and  the  voucher  number  of  the  last  transaction  affecting  the 
record  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  that  are  required  in  the  letter 
of  credit  withdrawal  process. 

2.10.1.3.3  Letter  of  credit  disbursement:  The  letter 
of  credit  disbursement  process  consists  of  a disbursement 
transaction,  an  adjustment  transaction,  an  update 
transaction,  a correction  transaction,  and  a reopening 
transaction  defined  as  follows: 
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• Disbursement  - a transaction  that  records  the 

disbursement  and  records  the  withdrawal  for  the 
contract  and  PR. 

• Adjustment  - a transaction  that  adjusts  the 

commitment,  obligation,  and  cost. 

• Update  - a transaction  that  updates  the  disbursement 
and  the  withdrawal.  The  transaction  must  have  been 
directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  disbursement,  the 
adjustment,  or  the  update  transaction. 

• Reopening  - a transaction  that  reopens  a contract  or 
grant  that  was  closed  during  the  current  year. 

The  input,  processing,  and  output  requirements  for  the 
disbursement  transaction.,  the  adjustment  transaction,  the 
update  transaction,  and  the  correction  transaction  are 
discussed  in  the  following  paragraphs.  The  requirements  for 
the  reopening  transaction  are  discussed  in  section  2.10.1.8. 

InjDut  - Figure  2.10-11  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
letter  of  credit  disbursement  process.  Figure  2.10-12 
defines  the  template  required  for  input  of  these  data 
elements. 

The  disbursement  transaction  is  specified  by  the  entry 
of  disbursement  dollars;  the  amount  entered  must  be 
positive.  The  adjustment  transaction  is  specified  by  the 
entry  of  commitment/obligation  dollars  and/or  cost  dollars; 
the  amounts  entered  may  be  either  positive  or  negative. 
Figure  2.10-13  contains  a list  of  these  transactions  and  the 
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Data 

element 

Element 

required 

Source 

Error 

type 

Inmit/Edit  recruirements 

Error 

code 

’AS  Of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  Bhen  input,  oust  be  numeric 
and  conform  to  all  normal  date  edits. 

B100 

B101 

Contract/ 

Grant 

number 

Yes 

Form  1031 

Fatal 

input  for  all  disbursement,  adjustment,  update,  and 
correction  transactions.  Positions  1 and  2 must  be 
a valid  contract  or  grant  prefix. 

B06O 

Contract 

Schedule 

Humber 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  cor- 
rection transactions  when  the  distribution  is  to  be 
limited  to  a specific  Contract  Schedule  Number. 

Must  be  alphabetic.  Bust  not  be  input  when  the  Con- 
tract/Grant Number  indicates  a grant.  Bust  not  be 
input  when  the  PR  Number  and  Suffix  are  entered. 

B380 

B381 

Disbursement 

Dollars 

Conditional 

Form  1031 

Fatal 

Input  for  all  disbursement  and  update  transactions  and 
for  the  correction  transaction  when  it  is  to  be  correc- 
ted. For  a disbursement  transaction,  must  be  numeric 
and  greater  than  0.  For  an  update  or  correction  trans- 
action, must  be  numeric  and  not  equal  to  0. 

B700 

B701 

B702 

B703 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  Position  1 must  be  J • Positions  2 
through  b must  be  numeric. 

B930 

B931 

Commitment/ 

Obligation 

Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjustment 
is  to  be  made  to  the  commitment  and  the  obligation 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  Bust  be  numeric  and  not  egual  to  0. 

Bust  have  the  same  sign  as  cost  dollars. 

B651 

B652 

B656 

Cost  Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjust- 
ment is  to  be  made  to  the  cost  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  Bust  be 
numeric  and  not  egual  to  0.  Bust  have  the  same  sign 
as  commitment/obligation  dollars. 

B63 1 
B632 

Purchase 

Request 

Number 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  correc- 
tion transactions  when  the  transaction  is  entered  at 
the  PR  level.  Positions  1 through  8 must  be  numeric. 
Position  9 must  be  alphabetic  or  blank. 

B301 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  correc- 
tion transactions  when  the  transaction  is  entered  at 
the  PR  level  and  the  suffix  is  other  than  the  base 
Suffix.  Bust  be  numeric. 

B311 

Reopening 

Update 

Ho 

Optional 

None 

User  supplied 

None 

Fatal 

Bust  not  be  input. 

Transaction  modifier  indicating  that  the  transaction 
is  an  update.  Input  only  when  the  transaction  is  an 
update.  Both  the  update  transaction  and  the  correc- 
tion transaction  must  not  be  specified. 

None 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction  is 
a correction.  Both  the  update  transaction  and  the 
correction  transaction  must  not  be  specified. 

B062 

Figure  2.10-11.  - Letter  of  Credit  Disbursement  input  and  edit  requirements. 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

****TEMPLATE  NO.  B5  - LETTER  OF  CREDIT  DISBURSEMENT 

CONTRACT/GRANT  NO.  CONTRACT  SCHEDULE 

DISBURSEMENT  $. , , . ± VOUCHER  NO.  

ADJUSTMENT:  C/O  t , . ± COST  $ 

PR  LEVEL  ENTRY:  PURCHASE  REQUEST  NO.  

REOPENING  _ 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


,t * ^ 

SUFFIX 


Figure  2.10-12.  - Letter  of  Credit  Disbursement  template. 


Tr ansaot i on  Dollar  amounts 

Disbursement  Disbursement  dollars 

Adjustment  Commitment/Obligation  dollars 

Cost  dollars 


Figure  2.10-13.  - Letter  of  credit  disbursement 
and  adjustment  transactions. 
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amount  or  amounts  that  must  or  may  be  entered  for  each 
transaction.  The  update  transaction  is  specified  by  the 
update  indicator  and  the  entry  of  disbursement  dollars;  the 
amount  entered  may  be  either  positive  or  negative.  The 
correction  transaction  is  specified  by  the  correction 
indicator;  any  data  elements  that  are  incorrect  may  be 
entered.  An  adjustment  transaction  may  be  entered  alone  or 
with  the  disbursement  transaction.  Both  an  update 
transaction  and  a correction  transaction  may  not  be  entered 
at  the  same  time. 

Processing  - Each  of  the  transactions  in  the  letter  of 
credit  disbursement  process,  whether  it  is  a disbursement, 
adjustment,  or  correction  transaction,  may  be  entered  at 
either  the  contract  level  or  the  PR  level.  If  the 
transaction  is  entered  at  the  contract  level,  the  system 
must  select  a PR  according  to  the  oldest  PR  first  criteria. 
If  the  transaction  is  entered  at  the  PR  level,  the  PR  is  the 
PR  specified  on  the  template.  The  contract  record  to  be 
updated  is  defined  by  the  contract  or  grant  number  entered 
on  the  template  and  the  performance  record  by  the  PR  Number 
and  Suffix  entered  on  the  template  or  selected  by  the 
system.  For  the  transactions  in  the  letter  of  credit 
disbursement  process,  both  records  must  exist  and  be  open. 
The  specific  transaction  requirements  are  discussed  by 
transaction  in  the  following  paragraphs. 

Disbursement 

The  disbursement  transaction  inputs  and  records  the 
disbursement  and  the  withdrawal.  Each  transaction  must 
update  a letter  of  credit  withdrawal  record,  a letter  of 
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credit  control  record,  a contract  record,  and  a performance 
record . 

For  the  disbursement  transaction,  the  letter  of  credit 
withdrawal  record  may  or  may  not  already  exist.  If  the 
record  does  not  exist,  it  must  be  created.  The  withdrawal 
amount  from  the  template  must  update  the  withdrawal  amount 
from  the  record.  For  any  PY,  the  updated  withdrawal  amount 
for  that  PY  must  not  exceed  the  issuance  amount  for  that  PY 
from  the  letter  of  credit  issuance  record. 

The  record  must  be  created  with  the  following  data 
elements : 


• Letter  of  credit  number 

• Program  Year 

• Withdrawal  dollar  amount 

The  record  is  defined  by  the  letter  of  credit  number  and  PY. 
The  letter  of  credit  number  is  obtained  from  the  contract 
record,  and  PY  is  obtained  from  the  performance  record. 

The  disbursement  from  the  template  must  update  the 
disbursement  from  the  letter  of  credit  control  record.  The 
letter  of  credit  control  record  is  defined  by  the  letter  of 
credit  number.  For  the  disbursement  transaction,  the  record 
must  exist.  The  updated  disbursement  must  not  exceed  the 
withdrawal  amount. 

If  the  transaction  is  entered  at  the  contract  level, 
the  disbursement  from  the  template  must  update  the 
disbursement  and  the  withdrawal  amount  from  the  contract 
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record.  A cost  increment  will  be  required  if  the  updated 
disbursement  exceeds  the  cost.  The  updated  withdrawal 
amount  must  not  exceed  the  issuance  amount,  and  the  updated 
disbursement  must  not  exceed  the  obligation.  The 
disbursement,  the  withdrawal  amount,  and  any  cost  increment 
must  be  distributed  to  the  PR's  with  the  oldest  PR  first. 
The  disbursement  and  the  withdrawal  amount  must  be 
distributed  to  the  PR's  up  to  the  issuance  amount.  The  cost 
increment  must  be  distributed  to  each  PR  such  that  the  cost 
for  the  PR  is  not  less  than  the  disbursement. 

If  a contract  schedule  is  entered,  the  disbursement 
from  the  template  must  still  update  the  disbursement  and  the 
withdrawal  amount  from  the  contract  record,  but  the  rest  of 
the  processing  must  be  restricted  to  the  schedule.  A cost 
increment  will  be  required  if  the  updated  disbursement  for 
the  schedule  exceeds  the  cost  for  the  schedule.  The  updated 
withdrawal  amount  must  not  exceed  the  issuance  amount,  and 
the  updated  disbursement  must  not  exceed  the  obligatxon. 
The  disbursement,  the  withdrawal  amount,  and  any  cost 
increment  must  be  distributed  only  to  PR's  with  the 
schedule.  Any  cost  increment  must  update  the  cost  from  the 
contract  record. 

If  the  transaction  is  entered  at  the  PR  level,  the 
disbursement  from  the  template  must  still  update  the 
disbursement  and  the  withdrawal  amount  from  the  contract 
record,  but  the  rest  of  the  processing  must  be  restricted  to 
the  PR.  The  disbursement  and  the  withdrawal  amount  from  the 
template  must  be  applied  to  the  PR.  A cost  increment  will 
be  required  if  the  updated  disbursement  from  the  performance 
record  exceeds  the  cost  from  the  performance  record.  The 

J 
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updated  withdrawal  amount  must  not  exceed  the  issuance 
amount,  and  the  updated  disbursement  must  not  exceed  the 
obligation.  Any  cost  increment  must  update  the  cost  from 
the  contract  record. 

The  disbursement  transaction  must  update  the  voucher 
number.  The  voucher  number  from  the  template  must  be 
overlaid  on  the  voucher  number  from  the  letter  of  credit 
withdrawal  record,  the  letter  of  credit  control  record,  and 
the  performance  record.  Only  the  voucher  number  of  the  last 
transaction  affecting  the  record  must  be  maintained. 

Adjustment 

The  adjustment  transaction  inputs  and  records  changes 
to  the  commitment,  obligation,  and  cost.  An  adjustment  to 
the  commitment  and  obligation  might  be  the  deobligation  of 
excess  funds.  An  adjustment  to  the  cost  might  be  the 
shifting  of  the  cost  from  one  PR  associated  with  the 
contract  or  grant  to  another.  Each  transaction  must  update 
a contract  record  and  a performance  record.  Both  records 
must  exist  and  be  open. 

The  first  adjustment  transaction  is  an  adjustment  to 
the  commitment  and  obligation  only.  The 
commitment/obligation  from  the  template  must  update  the 
obligation  from  the  contract  record.  A reduction  in  the 
cost  will  be  required  if  the  updated  obligation  is  less  than 
the  cost.  The  updated  obligation  must  not  be  less  than  the 
issuance  amount  or  the  disbursement,  and  the  updated  cost 
must  not  be  less  than  the  disbursement.  An  increase  in  the 
obligation  must  be  applied  to  the  newest  PR;  a reduction 
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must  be  distributed  to  the  PR's  with  the  newest  PR  first. 
The  commitment  must  be  increased  or  reduced  for  each  PR  for 
which  the  obligation  is  increased  or  reduced.  The  funds 
must  be  obtained  from  or  returned  to  the  PWA  account  or 
accounts  specified  by  the  accounting  information  of  the 
performance  record  or  records.  Any  increase  in  the 
commitment  must  not  exceed  the  preestablished  limits.  The 
balance  or  the  issues  of  the  PWA  account  must  be  sufficient. 

The  second  adjustment  transaction  is  an  adjustment  to 
the  commitment,  obligation,  and  cost.  The 
commitment/obligation  and  the  cost  from  the  template  must 
update  the  obligation  and  the  cost  from  the  contract  record. 
The  updated  obligation  must  hot  be  less  than  the  issuance  or 
the  disbursement;  the  updated  cost  must  not  be  greater  than 
the  updated  obligation;  and  the  updated  cost  must  not  be 
less  than  the  disbursement.  An  increase  in  the  obligation 
and  the  cost  must  be  applied  to  the  newest  PR;  a reduction 
must  be  distributed  to  the  PR's  with  the  newest  PR  first. 
The  commitment  must  be  increased  or  reduced  for  each  PR  for 
which  the  obligation  is  increased  or  reduced.  The  funds 
must  be  obtained  from  or  returned  to  the  appropriate  PWA 
account. 

The  third  adjustment  transaction  is  an  adjustment  to 
the  cost  only.  The  cost  from  the  template  must  update  the 
cost  from  the  contract  record.  The  updated  cost  must  not  be 
greater  than  the  obligation  or  less  than  the  disbursement. 
An  increase  in  the  cost  must  be  applied  to  the  newest  PR;  a 
reduction  must  be  distributed  to  the  PR's  with  the  newest  PR 
first. 
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The  adjustment  transaction  may  be  entered  at  either  the 
contract  level  or  the  PR  level.  The  processing  requirements 
for  the  transaction  entered  with  a contract  schedule  or 
entered  at  the  PR  level  correspond  to  those  for  the 
disbursement  transaction. 

Update  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Letter  of  credit  records, 
contract  records,  and  performance  records  must  be  updated  or 
corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that,  in  all 
cases,  the  amounts  entered  may  be  either  positive  or 
negative.  Amounts  from  the  letter  of  credit  records, 
contract  records,  and  performance  records  must  be  increased 
or  reduced.  The  normal  processing  edits  must  be  satisfied; 
in  addition,  a negative  update  or  correction  must  not  reduce 
any  amounts  from  any  of  the  records  below  0.  For  the  letter 
of  credit  disbursement  process,  the  dollar  data  elements  are 
disbursement  dollars  for  the  update  transaction  and 
disbursement  dollars,  commitment/obligation  dollars,  and 
cost  dollars  for  the  correction  transaction.  The  processing 
requirements  for  the  correction  of  information  data  elements 
specify  that  the  new  value  of  the  element  be  overlaid  on  the 
old.  The  only  information  data  element  is  the  voucher 
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number.  If  any  of  the  control  data  elements  are  entered 
incorrectly,  the  transaction  must  be  reversed  and  a new 
transaction  entered.  The  control  data  elements  are  the 
contract  number,  contract  schedule,  and  the  PR  Number  and 
Suffix. 

Any  cost  increments  made  automatically  by  the  system 
when  the  disbursement  was  greater  than  the  cost  cannot  be 
corrected  automatically  by  the  system.  The  updates  or 
corrections  must  be  made  manually  by  a separate  transaction. 

In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  letter  of  credit 
withdrawal  record,  the  letter  of  credit  control  record,  and 
the  performance  record.  Only  the  voucher  number  of  the  last 
transaction  affecting  the  records  must  be  maintained. 

The  update  and  correction  of  transactions  for  the 
update  or  correction  of  dollar  data  elements  or  control  data 
elements  may  be  entered  at  either  the  contract  level  or  the 
PR  level.  The  processing  requirements  for  the  transaction 
entered  with  a contract  schedule  or  entered  at  the  PR  level 
correspond  to  those  for  the  disbursement  transaction.  The 
correction  transaction  for  the  correction  of  information 
data  elements  should  be  entered  only  at  the  PR  level. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 
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Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  letter  of 
credit  disbursement  process. 

2.10.1.4  T-order disbursement.  The  T-order 

disbursement  process  inputs  and  records  the  disbursement  for 
T-orders  and  BPA's.  Payments  are  normally  made  and  the 
disbursement  recorded  upon  receipt  of  an  invoicing  document 
and  either  the  receipt  of  the  equipment  or  supplies  invoiced 
or  the  certification  of  the  invoicing  document  by  an 
authorized  contracting  officer.  The  disbursement  is  entered 
at  the  PR  level  with  the  disbursement  being  applied  to  the 
specific  PR  indicated  on  the  template. 

The  T-order  disbursement  process  consists  of  a series 
of  disbursement  transactions,  an  adjustment  transaction,  an 
update  transaction,  a correction  transaction,  a reopening 
transaction,  and  a cancelled  check  transaction  defined  as 
follows: 


• Disbursement  - a transaction  that  records  the 

disbursement . 

• Adjustment  - a transaction  that  adjusts  commitment, 
obligation,  and  cost. 

• Update  - a transaction  that  updates  the 

disbursement.  The  transaction  must  have  been 

directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  disbursement,  the 
adjustment,  or  the  update  transaction. 

• Reopening  - a transaction  that  reopens  a PR  that  was 
closed  during  the  current  year. 
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• cancelled  check  - a transaction  that  records  the 
cancellation  of  a check  and  the  reversal  of  the 
original  disbursement. 

The  various  disbursement  transactions  are  defined  as 
follows: 

• Net  disbursement  - a transaction  that  records  a net 
disbursement,  which  is  defined  as  any  payment  that 
is  not  a deposit  on  containers,  a payment  by  others, 
a payment  on  reimbursable  orders,  or  an  advance. 

• Deposit  on  containers  - a transaction  that  records  a 
payment  for  a deposit  on  containers,  which  is 
defined  as  a payment  for  a deposit  on  a drum  or 
container.  The  deposit  on  containers  is  a special 
type  of  disbursement;  it  must  be  recorded  both  as  a 
deposit  on  containers  and  as  a disbursement. 

• payment  by  others  - a transaction  that  records  a 
payment  by  others,  which  is  defined  as  a payment 
made  by  some  governmental  agency  other  than  JSC  but 
recorded  as  a JSC  disbursement  because  it  pertains 
to  JSC  activities.  These  payments  may  be  either  a 
foreign  payment  other  than  Canadian  which  is  made  by 
the  Treasury  Regional  Disbursing  Office  serving  the 
foreign  country  or  a payment  such  as  military  pay 
made  by  NASA  Headquarters.  The  payment  by  others  is 
a special  type  of  disbursement;  it  must  be  recorded 
both  as  a payment  by  others  and  as  a disbursement. 

• Payment  on  reimbursable  orders  - a transaction  that 
records  a payment  on  a reimbursable  order,  which  is 
defined  as  a payment  on  a T-order  or  BP  A for  which 
JSC  is  to  be  reimbursed  later  by  some  non-NASA 
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source.  The  payment  on  reimbursable  orders  is  a 
special  type  of  disbursement;  it  must  be  recorded 
both  as  a payment  on  reimbursable  orders  and  as  a 
disbursement . 

• Advance  established  - a transaction  that  records  an 
advance  payment,  which  is  defined  as  a payment  to 
some  other  governmental  agency  that  is  actually  made 
but  for  which  the  cost  and  disbursement  cannot  be 
recorded. 

• Advance  liguidated  - a transaction  that  records  the 
liquidation  of  an  advance.  The  advance  liguidated 
must  be  recorded  as  a disbursement. 

• Discount  - a transaction  that  records  a discount, 
which  is  defined  as  an  amount  invoiced  but  not  paid 
resulting  from  the  contractor,  vendor,  or  agency 
authorizing  reductions  in  payments  for  prompt 
payment  or  volume  purchasing  and  those  conditions 
being  satisfied.  Where  a discount  is  taken,  the 
discount  amount  must  be  computed  manually  as  a 
percentage  of  the  amount  invoiced.  The  amount  paid 
is  the  amou-nt  invoiced  less  the  discount. 

A simple  invoice  may  initiate  several  disbursement 
transactions.  One  situation  might  be  an  invoice  which  is 
totally  for  a net  disbursement;  a net  disbursement 

transaction  would  be  the  only  transaction  required.  A 
second  situation  might  be  an  invoice  which  is  totally  for  a 
payment  by  others;  a payment  by  others  transaction  would  be 
the  only  transaction  required.  A third  situation  might  be 
an  invoice  which  is  partially  for  a deposit  on  containers;  a 
deposit  on  containers  transaction  would  be  required  for  the 
deposit  on  containers  amount,  and  a net  disbursement 
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transaction  would  be  required  for  the  remainder  of  the 
amount  invoiced.  A fourth  situation  might  be  an  invoice 
which  is  totally  for  a net  disbursement  but  for  which  a 
discount  is  taken;  a discount  transaction  would  be  required 
for  the  discount  amount,  and  a net  disbursement  transaction 
would  be  required  for  the  remainder  of  the  amount  invoiced. 
Many  such  combinations  of  transactions  are  possible.  The 
transactions  for  any  single  invoice  may  be  input  at  the  same 
time;  however,  the  requirements  for  each  transaction  are 
discussed  separately. 

The  input,  processing,  and  output  requirements  for  the 
disbursement  transactions,  the  adjustment  transaction,  the 
update  transaction,  and  the  correction  transaction  are 
discussed  in  the  following  paragraphs.  The  requirements  for 
the  reopening  transaction  are  discussed  in  section  2.10.1.8. 
The  requirements  for  the  cancelled  check  transaction  are 
discussed  in  section  2.10.1.9. 

Input  - Figure  2.10-14  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
T-order  disbursement  process.  Figure  2.10-15  defines  the 
template  required  for  input  of  these  data  elements. 

The  various  disbursement  transactions  are  specified  by 
the  entry  of  the  appropriate  disbursement  dollar  amounts; 
the  amounts  entered  must  be  positive.  The  adjustment 
transaction  is  specified  by  the  entry  of 
commitment/obligation  dollars  and/or  cost  dollars;  the 
amounts  entered  may  be  either  posit iv e or  negative.  Fig ure 
2. 10-16  contains  a list  of  these  transactions  and  the  amount 
or  amounts  that  must  or  may  be  entered  for  each  transaction. 
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Data 

element 

Element 

required 

Source 

Error 

type 

Tnpnt/Edit  requirements 

Error 

code 

'As  of1 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B100 

B101 

Purchase 

Request 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  disbursement,  adjustment,  update,  and  cor- 
rection transactions.  Positions  1 through  8 must  be 
numeric.  Position  9 must  be  alphabetic  or  blank. 

B300 

B301 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  cor- 
rection transactions  when  the  suffix  is  other  than 
the  base  Suffix.  Bust  be  numeric. 

B311 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions  and 
for  the  correction  transaction  when  it  is  to  be  cor- 
rected- Position  1 must  be  J , and  positions  2 through 
4 must  be  numeric,  or  all  must  be  numeric. 

B930 

B931 

Extent  of 
payment 

Conditional 

User  supplied 

Fatal 

Transaction  modifier.  Input  for  all  disbursement  and 
update  transactions  and  for  the  correction  transaction 
when  a dollar  data  element  is  entered-.  Bust  be  either 
'partial*  or  'complete.'  Must  not  be  complete  unless 
net  disbursement  dollars  or  advance  liquidated  dollars 
are  input. 

B080 

C440 

C441 

Net 

disbursement 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  a net  disbursement  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  For  a disburse- 
ment transaction,  oust  be  numeric  and  greater  than  0. 

For  an  update  or  correction  transaction,  must  be  numeric 
and  not  equal  to  0- 

B701 

B702 

B703 

Discount 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when  there 
is  a discount  and  for  the  correction  transaction  when  it 
is  to  be  corrected.  For  a disbursement  transaction,  must 
be  numeric  and  greater  than  0.  For  an  update  or  correc- 
tion transaction,  must  be  numeric  and  not  egual  to  0. 

B711 

B712 

B713 

Deposit  on 
containers 
dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when  there 
is  a deposit  on  containers  and  for  the  correction  trans- 
action when  it  is  to  be  corrected.  For  a disbursement 
transaction,  must  be  numeric  and  greater  than  0.  For  an 
update  or  correction  transaction,  must  be  numeric  and  not 
equal  to  0. 

B731 

B732 

B733 

Payment  by 

others 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when  there 
is  a payment  by  others  and  for  the  correction  transaction 
when  it  is  to  be  corrected.  For  a disbursement  trans- 
action, must  be  numeric  and  greater  than  0.  For  an 
update  or  correction  transaction,  must  be  numeric  and 
not  equal  to  0. 

B74 1 
B742 
B743 

Figure  2-10-14.  - T-Order  Disbursement  input  and  edit  requirements. 
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Data 

element 

Element 

required 

Source 

Error 

tX£e 

Input/Edit  requirements 

Error 

code 

Advance 

established 

dollars 

Conditional 

user  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when  there 
is  an  advance  established  and  for  the  correction  trans- 
action, must  be  numeric  and  greater  than  0.  For  an  up- 
date or  correction  transaction,  must  be  numeric  and  not 
equal  to  0. 

B751 

B752 

B753 

Advance 

liquidated 

dollars 

Conditional 

user  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when  there 
is  an  advance  liquidated  and  for  the  correction  trans- 
action when  it  is  to  be  corrected.  For  a disbursement 
transaction,  must  be  numeric  and  greater  than  0.  For 
an  update  or  correction  transaction,  must  be  numeric 
and  not  egual  to  0. 

B761 

B762 

B763 

Commitment/ 

Obligation 

Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjustment 
is  to  be  made  to  the  commitment  and  obligation  and  for  the 
correction  transaction  when  it  is  to  be  corrected.  Must 
be  numeric  and  not  egual  to  0.  Must  have  the  same  sign 
as  cost  dollars. 

B651 

B652 

B656 

Cost  Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjustment 
is  to  be  made  to  the  cost  and  for  the  correction  trans- 
action when  it  is  to  be  corrected.  Must  be  numeric  and 
not  egual  to  0.  Must  have  the  same  sign  as  commitment/ 
obligation  dollars. 

B631 

B632 

Discount 

override 

Conditional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  discount  must 
not  reduce  the  commitment,  obligation,  and  cost.  Must 
not  be  input  unless  discount  dollars  are  input. 

B840 

Reopening 

No 

None 

None 

Must  not  be  input. 

None 

Cancelled 

check 

No 

None 

None 

Must  not  be  input. 

None 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction  is 
an  update.  Input  only  when  the  transaction  is  an  up- 
date. Both  the  update  transaction  and  the  correction 
transaction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction  is 
a correction.  Input  only  when  the  transaction  is  a 
correction.  Both  the  update  transaction  and  the  correc- 
tion transaction  must  not  be  specified. 

B062 

Figure  2.10-14.  - T-Order  Disbursement  input  and  edit  requirements  (concluded). 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

no.  N6  - T-ORDER  DISBURSEMENT 

PURCHASE  REQUEST  NO.  SUFFIX VOUCHER  NO.  — 

EXTENT  OF  PAYMENT:  PARTIAL  _ COMPLETE  _ 

NET  DISBURSEMENT  $ • ± DISCOUNT  $ , , 

DEPOSIT  ON  CONTAINERS  $ , . ± PAYMENT  BY  OTHERS  $ 

ADVANCE  ESTABLISHED  $ , , . ± ADVANCE  LIQUIDATED  $_ 

ADJUSTMENT  s C/O  $ , , . COST  $ , ± 

DISCOUNT  OVERRIDE  _ REOPENING  _ CANCELLED  CHECK  _ 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


f ' 


Figure  2.10-15.  - T-Order  Disbursement  template. 
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^ ... 


Transaction 


Dollar_ amounts 


disbursement 

Net  disbursement 

Deposit  on  containers 

Payment  by  others 

Payment  on  reimbursable  orders 

Advance  established 

Advance  liquidated 

Discount 

Adjustment 


Net  disbursement  dollars 
Deposit  on  containers  dollars 
Payment  by  others  dollars 
Net  disbursement  dollars 
Advance  established  dollars 
Advance  liquidated  dollars 
Discount  dollars 

Commitment/Obligation  dollars 
Cost  dollars 


Figure  2.10-16.  - T-order  disbursement 
and  adjustment  transactions. 


The  update  transaction  is  specified  by  the  update  indicator 
and  the  entry  of  the  appropriate  disbursement  dollar 
amounts;  the  amounts  entered  may  be  either  positive  or 
negative.  The  correction  transaction  is  specified  by  the 
correction  indicator;  any  data  elements  that  are  incorrect 
may  be  entered. 


Several  transactions  may  be  entered  at  the  same  time. 
A net  disbursement  transaction  may  be  entered  alone  or  with 
any  of  the  other  disbursement  transactions.  Only  one  of  (1) 
the  deposit  on  containers  transaction,  (2)  the  payment  by 
others  transaction,  or  (3)  the  payment  on  reimbursable 
orders  transaction,  may  be  entered  at  one  time.  A discount 
transaction  must  be  entered  with  one  of  the  transactions 
discussed  above;  it  may  not  be  entered  alone.  An  advance 
transaction  may  be  entered  alone  or  with  any  of  the  other 
disbursement  transactions;  however,  only  one  of  the  two 
transactions  may  be  entered  at  one  time.  An  adjustment 
transaction  may  be  entered  alone  or  with  any  of  the 
disbursement  transactions.  Both  an  update  transaction  and  a 
correction  transaction  may  not  be  entered  at  the  same  time. 


Processing  - Each  of  the  transactions  in  the  T-order 
disbursement  process,  whether  it  is  a disbursement, 
adjustment,  update,  or  correction  transaction,  must  be 
entered  at  the  PE  level.  The  performance  record  to  be 
updated  is  defined  by  the  PR  Number  and  Suffix  entered  on 
the  template;  for  the  transactions  in  the  T-order 
disbursement  process,  the  record  must  exist  and  be  open. 
The  specific  transaction  requirements  are  discussed  by 
transaction  in  the  following  paragraphs. 


i 
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Net  Disbursement 

The  net  disbursement  transaction  inputs  and  records  a 
net  disbursement.  Each  transaction  must  update  a 
performance  record. 

The  net  disbursement  transaction  may  be  either  a 
partial  payment  or  complete  payment.  In  either  case,  the 
disbursement  from  the  template  must  update  the  disbursement 
from  the  performance  record.  , For  partial  payments,  the 
updated  disbursement  plus  the  unliquidated  advance  must  not 
exceed  the  obligation;  a cost  increment  will  be  required  if 
the  updated  disbursement  exceeds  the  cost.  For  complete 
payments,  the  commitment,  obligation,  and  cost  must  be 
adjusted,  if  necessary,  to  equal  the  updated  disbursement; 
the  payment  must  not  be  complete  if  there  is  an  unliquidated 
advance.  If  the  commitment  is  changed,  the  funds  must  be 
obtained  from  or  returned  to  the  PWA  account  specified  by 
the  accounting  information  of  the  performance  record.  Any 
increase  in  the  commitment  must  not  exceed  the 
preestablished  limits.  The  balance  or  the  issues  of  the  PWA 
account  must  be  sufficient.  Any  change  in  cost  must  be 
applied  to  the  contract  record  for  those  T-orders  for  which 
contract  records  exist. 


Deposit  on  Containers 

The  deposit  on  containers  transaction  inputs  and 
records  a deposit  on  containers.  Each  transaction  must 
update  a performance  record.  The  deposit  on  containers  from 
the  template  must  update  the  deposit  on  containers  and  the 
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disbursement  from  the  performance  record.  The  transaction 
may  be  either  partial  or  complete. 


Payment  bv  Others 


The  payment  by  others  transaction  inputs  and  records  a 
payment  by  others.  Each  transaction  must  update  a 
performance  record.  The  payment  by  others  from  the  template 
must  update  the  payment  by  others  and  the  disbursement  from 
the  performance  record.  The  transaction  may  be  either 
partial  or  complete. 

Payment  on  Reimbursable  Orders 

The  payment  on  reimbursable  orders  transaction  inputs 
and  records  a payment  on  a reimbursable  order.  Each 
transaction  must  update  a performance  record.  Payments  on 
reimbursable  orders  are  not  specifically  identified  as  such 
on  the  template;  the  payment  is  input  as  a net  disbursement. 

The  disbursement  from  the  template  must  update  the 
disbursement  from  the  performance  record.  If  the  PR  has  a 
reimbursable  MR,  the  disbursement  is  a payment  on 
reimbursable  orders.  The  disbursement  must  then  update  the 
payment  on  reimbursable  orders  from  the  performance  record. 
The  transaction  may  be  either  partial  or  complete. 

Advance  Established 

The  advance  established  transaction  inputs  and  records 
the  establishment  of  an  advance.  Each  transaction  must 
update  a performance  record.  The  advance  established  from 
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the  template  must  update  the  advance  established  from  the  j 

performance  record.  The  updated  advance  established  less  j 

the  advance  liquidated  plus  the  disbursement  must  not  exceed  j 

the  obligation.  The  transaction  may  be  partial  only.  j 

.j 

Advance  Liquidated  j 

. .1 

jl 

The  advance  liquidated  transaction  inputs  and  records  j 

the  liquidation  of  the  advance  and  the  recording  of  the  ] 

disbursement*  Each  transaction  must  update  a performance 
record*  The  advance  liquidated  from  the  template  must 
update  the  advance  liquidated  and  the  disbursement  from  the 
performance  record.  The  updated  advance  liquidated  must  not 
exceed  the  advance  established.  The  transaction  may  be 

either  partial  or  complete,  but  must  not  be  complete  if  an  j 

unliquidated  advance  remains.  j 

i ■ i 

.j 

Discount 

1 

The  discount  transaction  inputs  and  records  a discount.  | 

-j 

Each  transaction  must  update  a performance  record.  The  j 

discount  from  the  template  must  update  the  discount  from  the  j 

performance  record.  j 

1 

'■] 

If  the  disbursement  transaction  entered  with  the 
discount  transaction  is  a partial  payment  and  the  discount 

override  is  not  specified,  the  discount  must  reduce  the  4 

commitment  and  the  obligation.  A reduction  in  the  cost  will 
be  required  if  the  updated  obligation  is  less  than  the  cost. 

The  updated  obligation  must  not  be  less  than  the 
disbursement  plus  the  unliquidated  advance,  and  the  updated 
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cost  must  not  be  less  than  the  disbursement.  The  funds  must 
be  returned  to  the  appropriate  PWA  account. 

For  PR's,  funded  from  the  supply  carrier  account,  the 
system  must  generate  cost  distribution  transactions  to 
adjust  the  supply  carrier  account  and  appropriate 
Conventional  PWA  account  for  the  amount  of  the  discount. 
The  transactions  must  increase  the  issues  of  the  Carrier 
account  and  must  reduce  the  issues  of  the  Conventional 
account.  Both  the  Carrier  account  and  the  Conventional 
account  must  exist.  The  issues  of  the  Conventional  account 
must  not  be  reduced  below  0.  The  Carrier  account  -to  be 
updated  is  defined  by  HA,  PY,  FS,  RO,  and  the  first  five 
digits  of  the  PWC  from  the  performance  record.  The 
Conventional  PWA  account  is  defined  by  HA,  PY,  FS,  RO,  and  a 
constant  five-digit  PWC  if  FS  is  4 or  above;  by  HA,  PY,  FS, 
RO,  and  object  Class  if  FS  is  3 and  PY  is  the  current  year; 
and  by  HA,  PY,  FS,  and  RO  if  FS  is  3 and  PY  is  a prior  year. 

Each  of  the  disbursement  transactions  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

Adjustment 

The  adjustment  transaction  inputs  and  records  changes 
to  the  commitment,  obligation,  and  cost.  An  adjustment  to 
the  commitment  and  obligation  might  be  the  deobligation  of 
excess  funds.  An  adjustment  to  the  cost  might  be  the 
shifting  of  the  cost  from  one  PR  associated  with  the  T-order 
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to  another.  Each  transaction  must  update  a performance 
record.  The  record  must  exist  and  be  open. 


The  first  adjustment  transaction  is  an  adjustment  to 
the  commitment  and  obligation  only.  The 
commitment/obligation  from  the  template  must  update  the 
commitment  the  obligation  from  the  performance  record.  A 
reduction  in  the  cost  will  be  required  if  the  updated 
obligation  is  less  than  the  cost.  The  updated  obligation 
must  not  be  less  than  the  disbursement  plus  the  unliquidated 
advance,  and  the  updated  cost  must  not  be  less  than  the 
disbursement.  The  funds  must  be  obtained  from  or  returned 
to  the  PWA  account  specified  by  the  accounting  information 
of  the  performance  record.  Any  increase  in  the  commitment 
must  not  exceed  the  preestablished  limits.  The  balance  or 
the  issues  of  the  PWA  account  must  be  sufficient. 

The  second  adjustment  transaction  is  an  adjustment  to 
commitment,  obligation,  and  cost.  The  commitment/obligation 
and  the  cost  from  the  template  must  update  the  commitment, 
obligation,  and  cost  from  the  performance  record.  The 
updated  obligation  must  not  be  less  than  the  disbursement 
plus  the  unliquidated  advance,  and  the  updated  cost  must  not 
be  greater  than  the  updated  obligation  or  less  than  the 
disbursement.  The  funds  must  be  obtained  from  or  returned 
to  the  appropriate  PWA  account. 


The  third  adjustment  transaction  is  an  adjustment  to 
the  cost  only.  The  cost  from  the  template  must  update  the 
cost  from  the  performance  record.  The  updated  cost  must  not 
be  • greater  than  the  obligation  or  less  than  the 
disbursement. 


qpdate  and  correction 


The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Performance  records  must  be 
updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that,  in  all 
cases,  the  amounts  entered  may  be  either  positive  or 
negative.  Amounts  from  the  performance  records  must  be 
increased  or  reduced.  The  normal  processing  edits  must  be 
satisfied;  in  addition,  a negative  update  or  correction  must 
not  reduce  any  of  the  amounts  below  0.  For  the  T-order 
disbursement  process,  the  dollar  data  elements  are  net 
disbursement  dollars,  discount  dollars,  deposit  on 
containers  dollars,  payment  by  others  dollars,  advance 
established  dollars,  and  advance  liquidated  dollars  for  the 
update  transaction,  and  net  disbursement  dollars,  discount 
dollars,  deposit  on  containers  dollars,  payment  by  others 
dollars,  advance  established  dollars,  advance  liquidated 
dollars,  commitment/obligation  dollars,  and  cost  dollars  for 
the  correction  transaction.  The  processing  requirements  for 
the  correction  of  information  data  elements  specify  that  the 
new  value  of  the  element  be  overlaid  on  the  old.  The  only 
information  data  element  is  the  voucher  number.  If  any 
the  control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 


The  control  data  elements  are  the  PR  Number  and  Suffix, 
extent  of  payment,  and  discount  override. 

Any  cost  increments  made  automatically  by  the  system 
when  the  disbursement  was  greater  than  the  cost  for  a 
partial  payment  cannot  be  corrected  automatically  by  the 
system.  The  updates  or  corrections  must  be  made  manually  by 
a separate  transaction. 

In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  T-order 
disbursement  process. 

2.10.1.5  GBL disbursement . The  GBL  disbursement 

process  inputs  and  records  the  disbursement  for  GBL's. 
Payments  are  made  and  the  disbursement  recorded  on  receipt 
of  a Public  Voucher  for  Transportation  Charges  (Standard 
Form  1113).  The  disbursement  is  entered  at  the  PR  level 
with  the  disbursement  being  applied  to  the  specific  GBL 


indicated  on  the  template. 


The  GBL  disbursement  process  consists  of  a disbursement 
transaction,  an  adjustment  transaction,  an  update 
transaction,  a correction  transaction,  a reopening 
transaction,  and  a cancelled  check  transaction  defined  as 
follows: 


• Disbursement  - a transaction  that  records  the 
disbursement  and,  if  applicable,  the  discount. 

• Adjustment  - a transaction  that  adjusts  commitment, 
obligation,  and  cost. 

• Update  - a transaction  that  updates  the  disbursement 
and  the  discount.  The  transaction  must  have  ' been 
directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  disbursement,  the 
adjustment  , or  the  update  transaction. 

• Reopening  - a transaction  that  reopens  a GBL  that 
was  closed  during  the  current  year. 

• Cancelled  check  - a transaction  that  records  the 
cancellation  of  a check  and  the  reversal  of  the 
original  disbursement. 

The  input,  processing,  and  output  requirements  for  the 
disbursement  transaction,  the  adjustment  transaction,  the 
update  transaction,  and  the  correction  transaction  are 
discussed  in  the  following  paragraphs.  The  requirements  for 
the  reopening  transaction  are  discussed  in  section  2.10.1.8. 
The  requirements  for  the  cancelled  check  transaction  are 
discussed  in  section  2.10.1.9. 

Input.  - Figure  2.10-17  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
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oSf 

it 


Data 

Element 

Error 

Error 

element 

required 

Source 

type 

Input/Edit  requirements 

code 

* As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Government 
Bill  of 
Lading 
number 

Yes 

Form  1113 

Fatal 

Input  for  all  disbursement,  adjustment,  update,  and 
correction  transactions.  Position  1 must  be  alpha- 
betic. Positions  2 through  8 must  be  numeric. 

B420 

B421 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  cor- 
rection transactions  when  the  suffix  is  other  than 
the  base  Suffix.  Must  be  numeric. 

B311 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  Position  1 must  be  T . Positions  2 
through  6 must  be  numeric. 

B930 

B931 

Net 

disbursement 
doll  ars 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  For  a disbursement  transaction,  must  be 
numeric  and  greater  than  0.  For  an  update  or  cor- 
rection transaction,  must  be  numeric  and  not  equal 
to  0 . 

B701 

B702 

B703 

Discount 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  a discount  and  for  the  correction  trans- 
action when  it  is  to  be  corrected.  For  a disburse- 
ment transaction,  must  be  numeric  and  greater  than 
0.  For  an  update  or  correction  transaction,  must 
be  numeric  and  not  egual  to  0. 

B711 

B712 

B713 

Commitment/ 
Obligation/ 
Cost  Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  all  adjustment  transactions.  Must  be 
numeric  and  not  egual  to  0. 

B661 

B662 

Reopening 

No 

None 

None 

Must  not  be  input- 

None 

Cancelled 

check 

No 

None 

None 

Must  not  be  input. 

None 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  transaction 
and  the  correction  transaction  must  not  be  speci- 
fied . 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction  . 
is  a correction.  Both  the  update  transaction  and 
the  correction  transaction  must  not  be  specified. 

B062 

Figure  2.10-17.  - Government  Bill  of  Lading  Disbursement  input  and  edit  requirements. 


GBL  disbursement  process.  Figure  2.10-18  defines  the 
template  required  for  input  of  these  data  elements. 

The  disbursement  transaction  is  specified  by  the  entry 
of  net  disbursement  dollars  and,  if  applicable,  discount 
dollars;  the  amounts  entered  must  be  positive.  The 
adjustment  transaction  is  specified'  by  the  entry  of 
commitment/obligation/cost  dollars;  the  amount  entered  may 
be  either  positive  or  negative.  Figure  2.10-19  contains'  a 
list  of  these  transactions  and  the  amount  or  amounts  that 
must  or  may  be  entered  for  each  transaction.  The  update 
transaction  is  specified  by  the  update  indicator  and  the 
entry  of  net  disbursement  dollars  and/or  discount  dollars; 
the  amounts  entered  may  be  either  positive  or  negative.  The 
correction  transaction  is  specified  by  the  correction 
indicator;  any  data  elements  that  are  incorrect  may  be 
entered.  An  adjustment  transaction  may  be  entered  alone  or 
with  the  disbursement  transaction.  Both  an  update 
transaction  and  a correction  transaction  may  not  be  entered 
at  the  same  time. 

Processing  - Each  of  the  transactions  in  the  GBL 
disbursement  process,  whether  it  is  a disbursement, 
adjustment,  update,  or  correction  transaction,  must  be 
entered  at  the  PR  level.  The  performance  record  to  be 
updated  is  defined  by  the  GBL  number  and  Suffix  entered  on 
the  template;  for  the  transactions  in  the  GBL  disbursement 
process,  the  record  must  exist  and  be  open.  The  specific 
transaction  requirements  are  discussed  by  transaction  in  the 
following  paragraphs. 
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****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  M7  - GBL  DISBURSEMENT 

GBL  NO.  SUFFIX  VOUCHER  NO.  

NET  DISBURSEMENT  $ , , . ± DISCOUNT  $ , 

ADJUSTMENT:  C/O/C  $ , , • ± 

REOPENING  _ CANCELLED  CHECK  _ 

' FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


Figure  2.10-18.  - Government  Bill  o±  Lading 
Disbursement  template. 


Transaction 


Required  dollar  amounts 


Conditional  dollar  amounts 


Disbursement 

Adjustment 


Net  disbursement  dollars  Discount  dollars 

Co mmitment/Obligati on/Cost  dollars 


Figure  2.10-19.  - Government  Bill  of  Lading  disbursement  and  adjustment  transactions 


Disbursement 


The  disbursement  transaction  inputs  and  records  the 
disbursement  and,  if  applicable,  the  discount.  Each 
transaction  must  update  a performance  record. 


The  disbursement  from  the  template  must  update  the 
disbursement  from  the  performance  record.  The  commitment, 
obligation,  and  cost  must  be  adjusted,  if  necessary,  to 
equal  the  updated  disbursement.  If  the  commitment  is 
changed,  the  funds  must  be  obtained  from  or  returned  to  the 
PWA  account  specified  by  the  accounting  information  of  the 
performance  record.  Any  increase  in  the  commitment  must  not 
exceed  the  preestablished  limits.  The  balance  or  the  issues 
of  the  PWA  account  must  be  sufficient.  If  there  is  a 
discount,  it  must  update  the  discount  from  the  performance 
record.  The  disbursement  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

Adjustment 

The  adjustment  transaction  inputs  and  records  changes 
to  the  commitment,  obligation,  and  cost.  An  adjustment 
might  be  the  deobligation  of  a GBL.  Each  transaction  must 
update  a performance  record.  The  record  must  exist  and  be 
open. 

The  commitment/obligation/cost  from  the  template  must 
update  the  commitment,  the  obligation,  and  the  cost  from  the 
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performance  record.  The  updated  cost  must  not  be  less  than 
the  disbursement.  The  funds  must  be  obtained  from  or 
returned  to  the  appropriate  PWA  account. 

Update  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Performance  records  must  be 
updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that,  in  all 
cases,  the  amounts  entered  may  be  either  positive  or 
negative.  Amounts  from  the  performance  records  must  be 
increased  or  reduced.  The  normal  processing  edits  must  be 
satisfied;  in  addition,  a negative  update  or  correction  must 
not  reduce  any  of  the  amounts  below  0.  For  the  GBL 
disbursement  process,  the  dollar  data  elements  are  net 
disbursement  dollars  and  discount  dollars  for  the  update 
transaction  and  net  disbursement  dollars,  discount  dollars, 
and  commitment/obligation/cost  dollars  for  the  correction 
transaction.  The  processing  requirements  for  the  correction 
of  information  data  elements  specify  that  the  new  value  of 
the  element  be  overlaid  on  the  old.  The  only  information 
data  element  is  the  voucher  number.  If  any  of  the  control 
data  elements  are  entered  incorrectly,  the  transaction  must 
be  reversed  and  a new  transaction  entered.  The  control  data 
elements  are  the  GBL  number  and  Suffix. 


In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  GBL 
disbursement  process. 

2.10.1.6  MILSTRIP/FEDSTRIP disbursement . The 

MILS TRIP /FED STRIP  disbursement  process  inputs  and  records 
the  disbursement  for  MILSTRIP/FEDSTRIP  items.  Payments  are 
normally  made  and  the  disbursement  recorded  upon  receipt  of 
an  invoicing  document  [either  the  Voucher  for  Transfers 
Between  Appropriations  and/or  Funds  (Standard  Form  1080)  for 
MILSTRIP  or  the  Statement,  Voucher  and  Schedule  of 
Withdrawals  and  Credits  (GSA  Form  789)  for  FEDSTRIP  ] and  the 
receipt  of  the  equipment  or  supplies  invoiced.  The 
disbursement  is  entered  at  the  PR  level  with  the 
disbursement  being  applied  to  the  specific  MILSTRIP/FEDSTRIP 
item  indicated  on  the  template. 

The  MILSTRIP/FEDSTRIP  obligation  process  inputs  and 
records  the  commitment  and  the  obligation  for 
MILSTRIP/FEDSTRIP  items.  The  MILSTRIP/FEDSTRIP  obligation 
process  is  discussed  in  section  2.10.1.11. 


In  addition  to  the  disbursement,  an  advance  amount  must 
be  input  and  recorded.  For  MILSTRIP/FEDSTRIP , all  payments 
are  made  to  other  governmental  agencies.  The  payments  must 
be  made  even  if  the  order  has  not  been  received,  but  the 
cost  and  the  disbursement  cannot  be  recorded.  An  advance 
must  be  established  for  any  payment  for  which  the  order  has 
not  been  completely  received;  the  ’ disbursement  must  be 
recorded  when  the  advance  is  liquidated.  Advances  are 
established  only  for  limits  over  certain  dollar  amounts. 

The  MILSTRIP/FEDSTRIP  disbursement  process  consists  of 
a series  of  disbursement  transactions,  an  adjustment 
transaction,  an  update  transaction,  a correction 
transaction,  a reopening  transaction,  and  a cancelled  check 
transaction  defined  as  follows: 


• Disbursement  - a transaction  that  records  the 

disbursement . 

• Adjustment  - a transaction  that  adjusts  the 

commitment,  obligation,  and  cost. 

• Update  - a transaction  that  updates  the 

disbursement.  The  transaction  must  have  been 

directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  disbursement,  the 
adjustment,  or  the  update  transaction. 

• Reopening  - a transaction  that  reopens  a 

MILSTRIP/FEDSTRIP  item  that  was  closed  during  the 
current  year. 

• Cancelled  check  - a transaction  that  records  the 
cancellation  of  a check  and  the  reversal  of  the 
original  disbursement. 


The  various  disbursement  transactions  are  defined  as 
follows: 


• Net  disbursement  - a transaction  that  records  a net 
disbursement,  which  is  defined  as  a payment  for 
which  the  order  has  not  been  received  but  is  under 
the  appropriate  dollar  limit. 

• Advance  established  — a transaction  that  records  an 
advance  payment,  which  is  defined  as  a payment  for 
an  order  which  has  not  been  received  and  is  over  the 
appropriate  dollar  limit. 

• Advance  liquidated  - a transaction  that  records  the 
liquidation  of  the  advance  upon  receipt  of  the  items 
previously  paid  for.  The  advance  liquidated  must  be 
recorded  as  a disbursement. 

The  input,  processing,  and  output  requirements  for  the 
disbursement  transactions,  the  adjustment  transaction,  the 
update  transaction,  and  the  correction  transaction  are 
discussed  in  the  following  paragraphs.  The  requirements  for 
the  reopening  transaction  are  discussed  in  section  2.10.1.8. 
The  requirements  for  the  cancelled  check  transaction  are 
discussed  in  section  2.10.1.9. 

Input  - The  obligating  documents  for  MILSTRIP /FEDSTRIP 
are  received  in  the  Commercial  Accounts  Unit  in  the  form  of 
punched  cards,  the  Single  Line  Item  Requisition  Document 
(Standard  Form  1348M) . Because  the  cards  are  already 
punched  with  the  appropriate  control  information,  they  will 
be  used  for  much  of  the  input.  Template  input  will  also  be 
provided . 
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Figure  2.10-20  contains  a list  of  data  elements  that 
must  be  input  and  edits  that  must  be  performed  for  the 
MILSTRIP/FEDSTRIP  disbursement  process  with  template  input. 
Figure  2. 10-21  defines  the  template  required  for  input  of 
these  data  elements.  Figure  2.10-22  contains  a list  of  data 
elements  that  must  be  input  and  edits  that  must  be  performed 
for  the  MILSTRIP/FEDSTRIP  disbursement  process  with 
MILSTRIP/FEDSTRIP  card  input.  Figure  2.10-23  defines  the 
format  of  the  MILSTRIP/FEDSTRIP  cards. 

On  the  template,  the  various  disbursement  transactions 
are  specified  by  the  entry  of  the  appropriate  disbursement 
dollar  amounts;  the  amounts  entered  must  be  positive.  The 
adjustment  transaction  is  specified  by  the  entry  of 
commitment/obligation  dollars  and/or  cost  dollars;  the 
amounts  entered  may  be  either  positive  or  negative.  Figure 
2.  10-24  contains  a list  of  these  transactions  and  the  amount 
or  amounts  that  must  or  may  be  entered  for  each  transaction. 
The  update  transaction  is  specified  by  the  update  indicator 
and  the  entry  of  the  appropriate  disbursement  dollar 
amounts;  the  amounts  entered  may  be  either  positive  or 
negative.  The  correction  transaction  is  specified  by  the 
correction  indicator;  any  data  elements  that  are  incorrect 
may  be  entered. 

On  the  template,  several  transactions  may  be  entered  at 
the  same  time.  A net  disbursement  transaction  may  be 
entered  alone  or  with  any  of  the  other  disbursement 
transactions.  Only  one  of  the  advance  established 
transaction  or  the  advance  liquidated  transaction  may  be 
entered  at  one  time.  An  adjustment  transaction  may  be 
entered  alone  or  with  any  of  the  disbursement  transactions. 


Data 

element 

Element 

required 

Source 

Error 

Input/Edit  requirements 

Error 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B1 00 
B 1 0 1 

MILSTEIP/ 

FEDSTEXP 

number 

Yes 

Invoicing 

document 

Fatal 

Input  for  all  disbursement,  adjustment,  update,  and 
correction  transactions.  Must  be  numeric. 

B87  0 
B87 1 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  adjustment,  update,  and  cor- 
rection transactions  when  the  suffix  is  ether  than  the 
base  Suffix.  Must  be  numeric. 

B311 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions  and 
for  the  correction  transaction  when  it  is  to  be  cor- 
rected. Position  1 must  be  J , and  positions  2 through 
4 must  be  numeric,  or  all  must  be  numeric. 

B930 
B93  1 

Net 

disbursement 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  a net  disbursement  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  For  a dis- 
bursement transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction, 
must  be  numeric  and  not  equal  to  0. 

B701 

B702 

Final 

payment 

Conditional 

User  supplied 

B080 

Transaction  modifier.  Input  for  disbursement  up- 
date and  correction  transactions  when  the  transaction 
is  a final  payment.  Must  not  be  input  unless  net 
disbursement  dollars  or  advance  liquidated  dollars 
are  input. 

B081 

Advance 

established 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  an  advance  established  and  for  the  correc- 
tion transaction  when  it  is  to  be  corrected.  For  a 
disbursement  transaction,  must  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction,  must 
be  numeric  and  net  equal  to  0. 

B751 

B752 

B753 

Advance 

liquidated 

dollars 

Conditional 

user  supplied 

Fatal 

Input  for  disbursement  and  update  transactions  when 
there  is  an  advance  liquidated  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  For  a dis- 
bursement transaction,  oust  be  numeric  and  greater 
than  0.  For  an  update  or  correction  transaction, 
must  be  numeric  and  not  equal  to  0. 

B761 
B76  2 
B763 

Commitment/ 

Obligation 

Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjust- 
ment is  to  be  made  tc  the  commitment  and  obligation 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  Must  be  numeric  and  not  equal  to  0.  * 

B651 

B652 

B656 

Must  have  the  same  sign  as  cost  dollars. 


Figure  2.10-20.  - HILSTRIP/FEDSTEIP  Disbursement  input  and  edit  requirements  (template  input) 
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Data 

element 


Element 

required 


Source 


Error 

type 


A--  \ 
\ > 


Input/Edit  requirements 


Error 

code 


Cost  Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  the  adjustment  transaction  when  an  adjust- 
ment is  to  be  made  to  the  cost  and  for  the  correction 
transaction  when  it  is  to  be  corrected.  Must  be 
numeric  and  not  equal  to  0.  Must  have  the  same  sign 
as  comnitment/obligation  dollars. 

B631 

B632 

Reopening 

NO 

None 

None 

Must  not  be  input. 

None 

Cancelled 

check 

No 

None 

None 

Must  not  be  input. 

None 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  an  update.  Input  only  when  the  transaction  is  an 
update.  Both  the  update  transaction  and  the  correc- 
tion transaction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction 
is  a correction-  Both  the  update  transaction  and  the 
correction  transaction  must  not  be  specified. 

B062 

Figure  2.10-20*  - MILSTRIP/FEDSTRIP  Disbursement  input  and  edit  requirements  (template  input)  (concluded) 


****IFMS  SEPTEMBER  30,  1974  AS  OF  — / — / — 

**** TEMPLATE  NO.  M8  - MILSTRIP/FEDSTRXP  DISBURSEMENT 

MIL STRIP/FED STRIP  NO.  SUFFIX  VOUCHER  NO.  

NET  DISBURSEMENT  $ , r • — ± FINAL  PAYMENT  _ 

ADVANCE  ESTABLISHED  $ , , • — ± ADVANCE  LIQUIDATED  $ , # 

ADJUSTMENT:  C/O  $ r r • — ± C0ST  * # ' — ± 

REOPENING  _ CANCELLED  CHECK  _ 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


Figure  2.10-21.  - MILSTRIP/FEDSTRIP  Disbursement  template. 
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Data 

element 

Element 

required 

Source 

Error 

tx£e 

Tnput/Edit  requirements 

Error 

code 

MILSTRIP/ 

FEDSTRIP 

Number 

Yes 

Prepunched 

Fatal 

Input  for  all  transactions. 
Must  be  numeric. 

Already 

punched 

on  cards. 

B870 

B871 

Suffix 

Yes 

Prepunched 

Fatal 

Input  for  all  transactions. 
Must  be  numeric. 

Already 

punched 

on  cards  *, 

B310 

B311 

Dollar 

Amount 

Yes 

User  supplied 

Fatal 

Input  for  all  transactions, 
greater  than  0. 

Must  be 

numeric 

and 

B600 

S601 

BC04 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Transaction  indicator.  Must 
transaction. 

be  a valid  type 

of 

B010 

B012 

Voucher 

number 

Yes 

User  supplied 

Fatal 

Input  for  all  transactions.  Position  1 must  be  J , 
and  positions  2 through  4 must  be  numeric,  or  all 
must  be  numeric. 

B930 

B931 

t 

(:■■■■ 

p ‘ . Fi  re  2* 1 0-22 . - MI LSI RIP/FED STRIP  Disbursement  input  and  edit  requirements  (card  input). 


Columns 

Length 

Data  element 

1-8 

8 

MILSTRIP/FEDSTRIP  NO, 

9-11 

3 

S OFF IX 

52-59 

8 

AMOUNT  $ 

65-67 

3 

TYPE  OF  TRANSACTION 

68-73 

6 

VOUCHER  NUMBER 

Figure  2.10-23.  - MILSTRIP/FEDSTRIP 
cards  (disbursement)  . 
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Transaction 


Dollar  amounts 


Disbursement 
Net  disbursement 
Advance  established 
Advance  liquidated 


Net  disbursement  dollars 
Advance  established  dollars 
Advance  liquidated  dollars 


Adjustment 


Commitment/Obligation  dollars 
Cost  dollars 


Figure  2.10-24.  - MI LSTR IP/FED STRIP  disbursement 
and  adjustment  transactions. 


Both  an  update  transaction  and  a correction  transaction  may 
not  be  entered  at  the  same  time. 

On  the  MILSTRIP/FEDSTRIP  cards,  the  transactions  are 
specified  by  a transaction  indicator.  Only  disbursement 
transactions  may  be  entered,  and  because  there  is  room  for 
only  one  dollar  field  on  the  cards,  only  one  disbursement 
transaction  may  be  entered  at  a time.  The  net  disbursement 
transaction  and  the  advance  liquidated  transaction  must  be 
final  payments. 

Processing  - Each  of  the  transactions  in'  the 
MILSTRIP/FEDSTRIP  disbursement  process,  whether  it  is  a 
disbursement,  adjustment,  update,  or  correction  transaction, 
must  be  entered  at  the  PR  level.  The  performance  record  to 
be  updated  is  defined  by  the  MILSTRIP/FEDSTRIP  number  and 
Suffix  entered  on  the  template  or  card;  for  the  transactions 
in  the  MILSTRIP/FEDSTRIP  disbursement  process,  the  record 
must  exist  and  be  open.  The  specific  transaction 
requirements  are  discussed  by  transaction  in  the  following 
paragraphs. 


Net  Disbursement 

The  net  disbursement  transaction  inputs  and  records  a 
net  disbursement.  Each  transaction  must  update  a 
performance  record. 

The  disbursement  from  the  template  or  card  must  update 
the  disbursement  from  the  performance  record.  The 
commitment  and  the  obligation  must  be  increased,  if 
necessary,  to  equal  the  updated  disbursement  plus  the 


unliquidated  advance.  A cost  increment  will  be  required  if 
the  updated  disbursement  exceeds  the  cost.  If  the 
commitment  is  increased,  the  funds  must  be  obtained  from  the 
PWA  account  specified  by  the  accounting  information  of  the 
performance  record.  Any  increase  in  the  commitment  must  not 
exceed  the  preestablished  limits.  The  balance  of  the  PWA 
account  must  be  sufficient. 

If  the  transaction  is  a final  payment,  the  commitment 
and  the  obligation  must  be  increased  or  reduced,  if 
necessary,  to  equal  the  updated  disbursement.  A cost 
increment  will  be  required  if  the  updated  disbursement 
exceeds  the  cost;  a reduction  in  the  cost  will  be  required 
if  the  updated  obligation  is  less  than  the  cost.  If  the 
commitment  is  changed,  the  funds  must  be  obtained  from  or 
returned  to  the  appropriate  PWA  account.  Any  increase  in 
the  commitment  must  not  exceed  the  preestablished  limits. 
The  balance  or  the  issues  of  the  PWA  account  must  be 
sufficient.  The  transaction  must  not  be  a final  payment  if 
there  is  an  unliquidated  advance. 

Advance_Es tab li shed 

The  advance  established  transaction  inputs  and  records 
the  establishment  of  an  advance.  Each  transaction  must 
update  a performance  record. 

The  advance  established  from  the  template  or  card  must 
update  the  advance  established  from  the  performance  record. 
The  commitment  and  the  obligation  must  be  increased,  if 
necessary,  to  equal  the  disbursement  plus  the  updated 
advance  established  less  the  advance  liquidated.  If  the 
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commitment  is  increased,  the  funds  must  be  obtained  from  the 
appropriate  PWA  account.  The  transaction  must  not  be  a 
final  payment. 


Advance  Liquidated 

The  advance  liquidated  transaction  inputs  and  records 
the  liquidation  of  an  advance.  Each  transaction  must  update 
a performance  record. 

The  advance  liquidated  from  the  template  or  card  must 
update  the  advance  liquidated  and  the  disbursement  from  the 
performance  record.  A cost  increment  will  be  required  if 
the  updated  disbursement  exceeds  the  cost.  The  updated 
advance  liquidated  must  not  exceed  the  advance  established. 

If  the  transaction  is  a final  payment,  the  commitment 
and  the  obligation  must  be  decreased,  if  necessary,  to  equal 
the  updated  disbursement.  A reduction  in  the  cost  will  be 
required  if  the  updated  obligation  is  less  than  the  cost. 
If  the  commitment  is  decreased,  the  funds  must  be  returned 
to  the  appropriate  PWA  account.  The  transaction  must  not  be 
a final  payment  if  there  is  an  unliquidated  advance. 

Each  of  the  disbursement  transactions  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 
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Adjustment 


The  adjustment  transaction  inputs  and  records  changes 
to  the  commitment,  obligation,  and  cost.  An  adjustment  to 
the  commitment  and  obligation  might  be  the  deobligation  of  a 
MILS TRIP/FED STRIP  item.  Each  transaction  must  update  a 
performance  record.  The  record  must  exist  and  be  open. 

The  first  adjustment  transaction  is  an  adjustment  to 
the  commitment  and  obligation  only.  The 
commitment/obligation  from  the  template  must  update  the 
commitment  and  the  obligation  from  the  performance  record. 
A reduction  in  the  cost  will  be  required  if  the  updated 
obligation  is  less  than  the  cost.  The  updated  obligation 
must  not  be  less  than  the  disbursement  plus  the  unliquidated 
advance,  and  the  updated  cost  must  not  be  less  than  the 
disbursement.  The  funds  must  be  obtained  from  or  returned 
to  the  P W A account  specified  by  the  accounting  information 
of  the  performance  record.  Any  increase  in  the  commitment 
must  not  exceed  the  preestablij^hed  limits.  The  balance  or 
the  issues  of  the  PWA  account  must  be  sufficient. 

The  second  adjustment  transaction  is  an  adjustment  to 
the  commitment,  obligation,  and  cost.  The 
commitment/obligation  and  the  cost  from  the  template  must 
update  the  commitment,  obligation,  and  cost  from  the 
performance  record.  The  updated  obligation  must  not  be  less 
than  the  disbursement  plus  the  unliquidated  advance,  and  the 
updated  cost  must  not  be  greater  than  the  updated  obligation 
or  less  than  the  disbursement.  The  funds  must  be  obtained 
from  or  returned  to  the  appropriate  PWA  account. 


The  third  adjustment  transaction  is  an  adjustment  to 
the  cost  only.  The  cost  from  the  template  must  update  the 
cost  from  the  performance  record.  The  updated  cost  must  not 
be  greater  than  the  obligation  or  less  than  the 
disbursement . 

Update  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Performance  records  must  be 
updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that,  in  all 
cases,  the  amounts  entered  may  be  either  positive  or 
negative.  Amounts  from  the  performance  records  must  be 
increased  or  reduced.  The  normal  processing  edits  must  be 
satisfied;  in  addition,  a negative  update  or  correction  must 
not  reduce  any  of  the  amounts  below  0.  For  the 
MILSTRIP/FEDSTRIP  disbursement  process,  the  dollar  data 
elements  are  net  disbursement  dollars,  advance  established 
dollars,  and  advance  liquidated  dollars  for  the  update 
transaction  and  net  disbursement  dollars,  advance 
established  dollars,  advance  liquidated  dollars, 
commitment/obligation  dollars,  and  cost  dollars  for  the 
correction  transaction.  The  processing  requirements  for  the 
correction  of  information  data  elements  specify  that  the  new 
value  of  the  element  be  overlaid  on  the  old.  The  only 
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information  data  element  is  the  voucher  number.  If  any  of 
the  control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  control  data  elements  are  the  MILSTRIP/FEDSTRIP  number. 
Suffix,  and  final  payment. 

Any  cost  increments  made  automatically  by  the  system 
when  the  disbursement  was  greater  than  the  cost  for  a 
payment  which  was  not  a final  payment  cannot  be  corrected 
automatically  by  the  system.  The  updates  or  corrections 
must  be  made  manually  by  a separate  transaction. 

In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 


Output  - Section  2.10.2  discusses  the  standard 
responses  and  error  messages  required  in 
MILSTRIP/FEDSTRIP  disbursement  process. 


online 

the 


2.10.1.7  Costing.  The  costing  process  inputs  and 
records  the  cost  for  stock  items,  equipment,  and  supplies 
received  by  JSC  for  which  payment  has  not  been  made.  The 
cost  is  recorded  at  the  end  of  each  month  for  stock  items 
and  at  the  end  of  each  year  for  all  items.  The  cost  is 
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entered  at  the  PR  level  with  the  cost  being  applied  to  the 
specific  PR  or  MILSTRIP/FEDSTRIP  item  indicated  on  the 
template. 

The  costing  process  provides  a simple,  quick  means  of 
applying  the  cost.  It  should  be  used  for  those  areas,  such 
as  T-order's,  BPA*s,  and  MILSTRIP/FEDSTRIP  items,  which  have 
a high  volume  of  end-of -month  and  end-of-year  costing 
activity.  The  cost  for  the  low-volume  areas,  such  as 
contracts,  must  be  applied  using  the  normal  adjustment 
transaction. 


The  costing  process  consists  of  a costing  transaction 
and  a correction  transaction  defined  as  follows: 

• Costing  - a transaction  that  records  the  cost. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  the  costing  transaction. 

The  input,  processing,  and  output  requirements  for 
these  transactions  are  discussed  in  the  following  sections. 

InjDut  - Figure  2.10-25  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
costing  process  with  template  input.  Figure  2.10-26  defines 
the  template  required  for  input  of  these  data  elements. 
Figure  2.10-27  contains  a list  of  data  elements  that  must  be 
input  and  edits  that  must  be  performed  for  the  costing 
process  with  MILSTRIP/FEDSTRIP  card  input.  Figure  2.10-28 
defines  the  format  of  the  MILSTRIP/FEDSTRIP  cards. 
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Error 


Data 

element 

Element 

required 

Source 

Error 

Tnput/Edit  requirements 

code 

'As  of' 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the  ^ 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Purchase 

Request 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  costing  and  correction  transactions. 
Positions  1 through  8 must  be  numeric. ^ Position  9 
must  be  alphabetic  or  blank.  Hay  be  either  a PR 
Number  or  a HIL STRIP /FED STRIP  number. 

B300 

B301 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  costing  and  correction  transactions  when 
the  suffix  is  other  than  the  base  Suffix.  Must  be 
numeric. 

B311 

Cost  Dollars 

Yes 

User  supplied 

Fatal 

Input  for  all  costing  and  correction  transactions. 
For  a costing  transaction,  must  be  numeric  and 
greater  than  0.  For  a correction  transaction,  must 
be  numeric  and  not  egual  to  0. 

B63 1 
B631 
B633 

Final 

costing 

Conditional 

User  supplied 

Fatal 

Transaction  modifier.  Input  for  costing  and  ^ 
correction  transactions  when  the  transaction  is  a 
final  costing.  Input  only  for  MILSTRI P/FED STRIP 
items. 

None 

Correction 

Optional 

User  supplied 

None 

Transaction  modifier  indicating  that  the  transaction 
is  a correction  transaction.  Input  only  when  tne 
transaction  is  a correction  transaction. 

None 

Figure  2.10-25.  - Costing  input 


and  edit  requirements  (template  input) . 


****IFMS  SEPTEMBER  30r  1974  AS  OF 
♦♦♦♦TEMPLATE  NO.  M9  - COSTING 

PURCHASE  REQUEST  NO.  

COST  $ , r • ± FINAL 

CORRECTION  _ 


SUFFIX 

COSTING 


Figure  2.10-26.  - Costing  template. 
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Data 

Element 

Error 

Error 

element 

required 

Source 

type 

Input/Edit  requirements 

code 

MILSTRIP/ 

FEDSTRXP 

Number 

Yes 

Prepunched 

Fatal 

Input  for  all  transactions. 
Must  be  numeric. 

Already  punched 

on  cards. 

B87  0 
B871 

Suffix 

Yes 

Prepunched 

Fatal 

Input  for  all  transactions. 
Must  be  numeric. 

Already  punched 

on  cards. 

B3 1 0 
B311 

Dollar 

Amount 

Yes 

. User  supplied 

Fatal 

Input  for  all  transactions, 
greater  than  0. 

Must  be  numeric 

and 

B600 

B601 

B604 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Transaction  indicator.  Must 
transaction. 

be  a valid  type 

of 

BO  1 0 
B0 1 2 

Final 

costing 

Conditional 

User  supplied 

None 

Transaction  modifier.  Input  for  costing  transactions 
when  the  transaction  is  a final  costing. 

None 

Figure 


2.10-27.  - Costing  input  and  edit  requirements  ( HILSTRIP/FEDSTRIP  card  input) 


Columns 

Length 

Data  element 

1-3 

8 

MILS TRIP/FED STRIP  NO 

9-11 

3 

SUFFIX 

52-59 

8 

AMOUNT  $ 

65-67 

3 

TYPE.  OF  TRANSACTION 

74 

1 

FINAL  COSTING 

Figure  2.10— 28.  — MILSTRIP/FEDSTRIP 
cards  (costing)  , 
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On  the  template,  the  costing  transaction  is  specified 
by  the  entry  of  cost  dollars;  the  amount  entered  must  be 
positive.  The  correction  transaction  is  specified  by  the 
correction  indicator;  any  data  elements  that  are  incorrect 
may  be  entered.  On  the  MILSTRIP/FEDSTRIP  cards,  the 
transactions  are  specified  by  a transaction  indicator.  Only 
costing  transactions  may  be  entered  on'  the  cards. 

Processing  - Each  of  the  transactions  in  the  costing 
process,  whether  it  is  a costing  or  correction  transaction, 
must  be  entered  at  the  PR  level.  The  performance  record  to 
be  updated  is  defined  by  the  PR  Number  and  Suffix  or"  the 
MILSTRIP/FEDSTRIP  number  and  Suffix  entered  on  the  template 
or  card;  for  the  transactions  in  the  costing  process,  the 
record  must  exist  and  be  open.  The  specific  transaction 
requirements  are  discussed  by  transaction  in  the  following 
paragraphs. 


Costing 

The  costing  transaction  inputs  and  records  the  cost. 
Each  transaction  must  update  a performance  record.  The  cost 
from  the  template  or  card  must  update  the  cost  from  the 
performance  record.  For  a transaction  which  is  not  a final 
costing,  the  updated  cost  must  not  exceed  the  obligation. 
For  a transaction  which  is  a final  costing,  the  commitment 
and  the  obligation  must  be  adjusted,  if  necessary,  to  egual 
the  updated  cost.  If  the  commitment  is  changed,  the  funds 
must  be  obtained  from  or  returned  to  the  PWA  account 
indicated  by  the  accounting  information  of  the  performance 
record.  Any  increase  in  the  commitment  must  not  exceed  the 
preestablished  limits.  The  balance  or  the  issues  of  the  PWA 
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account  must  be  sufficient.  Final  costing  is  valid  only  for 
HI LSTF.XP/FED STRIP  items. 

Correction 

The  correction  transaction  inputs  and  records 
corrections.  Corrections  are  made  to-  either  dollar  data 
elements  or  control  data  elements;  for  the  costing  process, 
no  information  data  elements  exist.  Performance  records 
must  be  corrected  appropriately. 

The  processing  requirements  for  the  correction  of 
dollar  data  elements  are  basically  the  same  as  those  for  the 
original  transaction  except  that  the  amount  entered  may  be 
either  positive  or  negative.  Amounts  from  the  performance 
records  must  be  increased  or  reduced.  The  normal  processing 
edits  must  be  satisfied;  in  addition,  a negative  correction 
must  not  reduce  any  of  the  amounts  below  0 . The  only  dollar 
data  element  is  cost  dollars.  If  any  of  the  control  data 
elements  are  entered  incorrectly,  the  transaction  must  be 
reversed  and  a new  transaction  entered.  The  control  data 
elements  are  the  PR  Number  and  Suffix,  the  MILSTRIP/FEDSTRIP 
number  and  Suffix,,  and  final  costing. 

To  satisfy  audit  trail  requirements,  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  and  correction  transactions  must  be  identified  in 
the  transaction  history. 


Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  costing 
process. 
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2.10.1.8  Reopening.  The  reopening  process  reopens 
closed  contracts,  grants,  T-orders,  BPA's,  GBL's,  and 
MILSTRIP/FEDSTRIP  items.  Reopening  may  be  either  current 
year  reopening  or  prior  year  reopening. 

2.10.1.8.1  Current  year  reopening:  The  current  year 
reopening  process  removes  the  closed  indicator  from  contract 
and  performance  records  that  were  closed  during  the  year  but 
still  reside  on  the  performance  data  base.  No  dollar 
amounts  or  accounting  information  on  any  record  is  affected. 

Input  - The  current  year  reopening  transaction  is 
specified  by  the  reopening  indicator  on  the  various 
templates.  The  transaction  may  be  entered  alone  or  with  a 
disbursement  or  adjustment  transaction. 

Processing  - If  the  reopening  is  for  a T-order,  BPA, 
GBL,  or  MILSTRIP/FEDSTRIP  item,  the  performance  record  to  be 
reopened  is  defined  by  the  PR  number,  GBL  number,  or 
MILSTRIP/FEDSTRIP  number  and  Suffix  entered  on  the  template. 
For  the  current  year  reopening  transaction,  the  record  must 
exist  and  be  closed.  The  closed  indicator  must  be  removed 
from  the  record. 

If  the  reopening  is  for  a contract  or  grant,  the 
contract  record  to  be  reopened  is  defined  by  the  contract  or 
grant  number  entered  on  the  template.  If  the  transaction  is 
entered  at  the  contract  level,  all  performance  records 
associated  with  the  contract  must  be  reopened.  If  the 
transaction  is  entered  at  the  PR  level,  only  the  performance 
record  specified  by  the  PR  Number  and  Suffix  entered  on  the 
template  must  be  reopened.  For  the  current  year  reopening 
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transaction,  the  appropriate  records  must  exist  and  be 
closed.  The  closed  indicator  must  be  removed  from  the 
records.  If  the  reopening  transaction  is  entered  with 
another  transaction,  the  reopening  transaction  must  be 
processed  first. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 

Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  current  year 
reopening  process. 

2.10.1.8.2  Prior  year  reopening:  The  prior  year 
reopening  process  reestablishes  contract  and  performance 
records  that  were  closed  during  prior  years  and,  thus,  do 
not  still  reside  on  the  performance  data  base.  Once 
reopened,  the  records  are  available  for  normal  processing. 
The  prior  year  reopening  transaction  does  not  have  any 
effect  on  current  year  amounts. 

The  prior  year  reopening  process  consists  of  a 
reopening  transaction  and  a correction  transaction  defined 
as  follows: 

« Reopening  - a transaction  that  reestablishes  the 
performance  and  contract  records. 

• correction  - a transaction  that  corrects  any  data 
elements  entered  in  the  reopening  transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 
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ln£ut  - Figure  2. 10-29  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
prior  year  reopening  process.  Figure  2.10-30  defines  the 
template  required  for  input  of  these  data  elements. 

The  reopening  transaction  is  specified  by  the  entry  of 
reopening  dollars,  the  appropriate  disbursement  dollar 
amounts,  and  the  accounting  information;  the  amounts  entered 
must  be  positive.  The  correction  transaction  is  specified 
by  the  correction  indicator;  any  data  elements  that  are 
incorrect  may  be  entered. 

~ The  specific  transaction  requirements  are 
discussed  by  transaction  in  the  following  paragraphs. 

Reopening 

The  reopening  transaction  inputs  and  records  the 
reopening.  Each  transaction  must  create  a performance 
record  and,  if  the  reopening  is  for  a contract  or  grant, 
create  or  update  a contract  record. 

If  a contract  originally  had  several  performance 
records,  as  many  performance  records  as  necessary  may  be 
reopened.  The  contract  record  will  be  maintained  as  the 
contract-level  information  for  whichever  performance  records 
are  reopened.  If  all  of  the  original  performance  records 
are  not  reopened,  the  contract-level  information  will  not  be 
equal  to  that  for  the  original  contract. 
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If  the  reopening  is  for  a T-order,  BPA,  GBL,  or 
MILSTRIP/FEDSTRIP  item,  the  performance  record  to  be 
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Data 

element 

Element 

required 

Source 

Error 

£XEe 

In£Ub/Edit_reguirements 

Error 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions, 
input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits- 

B 1 00 
B 1 0 1 

Purchase 

Request 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  reopening  and  correction  transactions. 
Position  1 must  be  alphanumeric.  Positions  2 through 
8 must  be  numeric.  Position  9 must  be  alphabetic  or 
blank.  May  be  either  a PR,  a GBL,  or  a MILSTRIP/ 
FEDSTRIP  number. 

B300 

B301 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  reopening  and  correction  transactions  when 
the  suffix  is  other  than  the  base  Suffix.  Must  be 
numeric. 

B311 

Contract/ 

Order 

Number 

Conditional 

User  supplied 

Fatal 

Input  for  reopening  and  correction  transactions  for 
contracts,  grants,  and  T-orders.  Positions  1 ana  2 
must  be  a valid  contract,  grant,  or  T-order  prefix- 
May  be  either  a contract,  a grant,  or  a 1-order 
number. 

B361 

Reopening 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  all  reopening  transactions  and  for  the  cor- 
rection transaction  when  it  is  to  be  corrected.  For  a 
reopening  transaction,  must  be  numeric  and  greater  than 
0.  For  a correction  transaction,  must  be  numeric  and 
not  equal  to  0- 

B77  0 
B771 
B772 
B773 

Discount 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  reopening  transactions  when  there  is  a dis- 
count and  for  the  correction  transaction  when  it  is 
to  be  corrected.  For  a reopening  transaction,  must 
be  numeric  and  greater  than  0.  For  a correction 
transaction,  must  be  numeric  and  not  equal  to  0. 

B711 
B7 1 2 
B71 3 

Payment  by 

others 

dollars 

Conditional 

User  supplied 

Fatal 

Input  for  reopening  transactions  when  there  is  a pay- 
ment by  others  and  for  the  correction  transaction  when 
it  is  to  be  corrected.  For  a reopening  transaction, 
must  be  numeric  and  greater  than  0.  For  a correction 
transaction,  must  be  numeric  and  not  equal  to  0. 

B741 
B742 
B7  43 

Method  of 
Authority 

Conditional 

User  supplied 

Fatal 

Input  for  all  reopening  transactions  and  for  the  cor- 
rection transaction  when  it  is  to  be  corrected.  Must 
be  a valid  MA  but  not  97. 

B 1 10 
Bill 
B115 

Program  Year 

Conditional 

User  supplied 

Fatal 

Input  f07:  all  reopening  transactions  and  for  the  cor- 
rection transaction  when  it  is  to  be  corrected.  Must 
be  a valid  PY.  Also  validated  with  FS. 

B1 20 
B 1 2 1 
C5  00 
C508 

Figure  2.10-29.  - Prior  Year  Reopening  input  and  edit  requirements. 
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Error  Error 

tx^e  Inpat/Edit  requirements  code 

Fatal  Input  for  all  reopening  transactions  and  for  the  cor-  B130 

rection  transaction  when  it  is  to  be  corrected.  Must  B139 

be  a valid  FS.  Also  validated  with  PY.  C500 

C506 

C507 

C508 

C509 


C51 0 


Fatal  Input  for  all  reopening  transactions  and  for  the  cor-  B170 

rection  transaction  when  it  is  to  be  corrected.  Must  B171 

be  nine  digits  and  a valid  PWC.  B174 

Fatal  Input  for  all  reopening  transactions  and  for  the  cor-  B190 

rection  transaction  when  it  is  to  be  corrected.  Must  B191 

be  a valid  Object  Class. 

Fatal  Input  for  all  reopening  transactions  and  for  the  cor-  B200 

rection  transaction  when  it  is  to  be  corrected.  Must  B201 

be  a valid  RO. 

Fatal  Input  for  all  reopening  transactions  and  for  the  cor-  B320 

rection  transaction  when  it  is  to  be  corrected.  Must  B321 

be  a valid  Performing  Organization. 

Fatal  Input  for  reopening  transactions  when  available  and  B330 

for  the  correction  transaction  when  it  is  to  be  cor-  B331 

rected.  If  the  first  position  is  0 or  1,  must  be  a C506 

Centerwide  Job  Code  and  be  validated  with  FS  and  Per-  C509 

forming  Organization. 

Fatal  Input  for  reopening  transactions  when  available  and  B340 

for  the  correction  transaction  when  it  is  to  be  cor-  B341 

rected.  If  the  first  position  is  0 or  1,  must  be  a B342 

Centerwide  Job  Code  and  be  vlidated  with  FS  and  Per-  C507 

forming  Organization.  C510 

None  Input  for  reopening  transactions  for  BPA’s  and  for  the  None 

correction  transaction  when  it  is  to  be  corrected. 

Fatal  Input  for  reopening  transactions  and  for  the  correction  B880 

transaction  when  it  is  to  be  corrected.  See  figure  B881 

2.7-2  for  the  definition  of  these  codes. 

Fatal  Input  for  reopening  transactions  for  contracts  when  B380 

there  is  a contract  schedule  number  and  for  the 
correction  transaction  when  it  is  to  be  corrected. 

Must  be  alphabetic.  The  contract  schedule  is  the 
last  schedule  for  the  contract  or  grant. 


Year  Reopening  input  and  edit  requirements  (continued) . 


Data 

element 


Element 


Source 


Error 

code 


re 


Error 

type  Input/Edit  requirements 


Contractor 
name  code 

Conditional 

User  supplied 

Fatal 

Input  for  reopening  transactions  for  contracts, 
grants,  and  T-orders  and  for  the  correction  trans- 
action When  it  is  to  be  corrected.  Must  be  numeric. 

Amendment 

Number 

Conditional 

User  supplied 

Fatal 

Input  for  reopening  transactions  for  contracts  or 
grants  when  there  is  an  amendment  and  for  the  cor- 
rection transaction  when  it  is  to  be  corrected.  Must 
be  numeric.  The  Amendment  Number  is  the  last  amend- 
ment for  the  contract  or  grant. 

Correction 

Optional 

User  supplied 

None 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction 

is  a correction. 


B400 

B370 

None 


Figure  2.10-29.  - Prior  Year  Reopening  input  and  edit  requirements  (concluded). 


♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  0*  / / 

♦♦♦♦TEMPLATE  NO.  MB  - REOPENING  PRIOR  YEAR 

PURCHASE  REQUEST  NO.  SUFFIX  CONTRACT/ORDER  NO.  

REOPENING  $ , , _. ± DISCOUNT  $ , , . ± 

PAYMENT  BY  OTHERS  $ , . ± 

MA PY FS PWC  OBJECT  CLASS RESP  ORG 

PERF  ORG  PRIMARY  JOB  CODE  SECONDARY  JOB  CODE  

BPA  CALL  NO.  CONTRACT  TYPE  _ CONTRACT  SCHEDULE  _ 

CONTRACTOR  NAME  CODE  AMENDMENT  NO.  

CORRECTION 
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reopened  is  defined  by  the  PR,  GBL,  or  MILSTR IP/FEDS TRIP 
number  and  Suffix  entered  on  the  template.  For  the 
reopening  transaction,  the  record  must  not  exist.  The 
record  must  be  created  with  the  accounting  information  from 
the  template  and  with  reopening  dollars  from  the  template  as 
the  commitment,  obligation,  cost,  and  disbursement.  In 
addition,  discount  dollars  and  payment  by  others  dollars 
must  be  inserted  in  the  record. 

If  the  reopening  is  for  a contract  or  grant,  the 
contract  record  to  be  reopened  is  defined  by  the  contract  or 
grant  number  entered  on  the  template  and  the  performance 
record  by  the  PR  Number  and  Suffix.  For  the  reopening 
transaction,  the  performance  record  must  not  exist;  the 
contract  record  may  or  may  not  exist  depending  on  whether 
other  performance  records  for  the  contract  have  already  been 
reopened.  The  performance  record  must  be  created  with  the 
accounting  information  from  the  template  and  with  reopening 
dollars  from  the  template  as  the  commitment,  obligation, 
cost,  and  disbursement.  If  the  contract  record  does  not 
already  exist,  it  must  be  created  with  the  contract 
information  from  the  template  and  with  reopening  dollars 
from  the  template  as  the  obligation,  cost,  and  disbursement. 
If  the  contract  record  does  already  exist,  the  contract 
information  from  the  template  must  match  the  contract 
information  from  the  contract  record,  and  reopening  dollars 
from  the  template  must  update  the  obligation,  cost,  and 
disbursement  from  the  contract  record.  In  addition, 
discount  dollars  and  payment  by  others  dollars  must  be 
inserted  in  the  performance  record  and  be  inserted  in  or 
update  the  contract  record. 
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Correction 


The  correction  transaction  inputs  and  records 
corrections.  Corrections  are  made  to  either  dollar  data 
elements,  information  data  elements,  or  control  data 
elements.  Contract  records  and  performance  records  must  be 
corrected  appropriately. 

The  processing  requirements  for  the  correction  of 
dollar  data  elements  are  basically  the  same  as  those  for  the 
original  transaction  except  that,  in  all  cases,  the  amount 
entered  may  be  either  positive  or  negative.  Amounts'  from 
the  contract  and  performance  records  must  be  increased  or 
reduced.  The  normal  processing  edits  must  be  satisfied;  in 
addition,  a negative  correction  must  not  reduce  any  amounts 
from  any  of  the  records  below  0.  For  the  prior  year 
reopening  process,  the  dollar  data  elements  are  reopening 
dollars,  discount  dollars,  and  payment  by  others  dollars. 
The  processing  requirements  for  the  correction  of 
information  data  elements  specify  that  the  new  value  of  the 
element  be  overlaid  on  the  old.  The  information  data 
elements  are  the  accounting  information  and  the  contract 
information.  If  any  of  the  control  data  elements  are 
entered  incorrectly,  the  transaction  must  be  reversed  and  a 
new  transaction  entered.  The  control  data  elements  are  the 
PR  Number  and  Suffix  and  contract  number. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  and  correction  transactions  must  be  recorded  in  the 
transaction  history. 
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Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  prior  year 
reopening  process. 

2.10.1.9  Cancelled  check.  The  cancelled  check  process 
inputs  and  records  the  cancellation  of  a check  and  the 
reversal  of  the  original  disbursement.  The  cancelled  check 
process  is  applicable  to  the  contract,  grant,  T-order, 
MILSTRIP/FEDSTRIP,  GBL,  and  miscellaneous  disbursement 
processes. 

Input  - The  cancelled  check  transaction  is  specified  by 
the  cancelled  check  indicator  on  the  various  templates.  The 
transaction  may  not  be  entered  alone;  it  must  be  entered 
with  a disbursement  transaction  or  transactions  to  reverse 
the  original  disbursement  and  an  adjustment  transaction  or 
transactions  to  reverse  any  effect  the  original  disbursement 
may  have  had  on  the  commitment,  obligation,  and  cost.  The 
amounts  entered  for  the  disbursement  transaction  or 
transactions  and  the  adjustment  transaction  or  transactions 
must  be  negative.  A reopening  transaction  must  not  be 
entered  at  the  same  time. 

Processing  - If  the  cancelled  check  is  for  a T-order, 
BPA,  GBL,  or  MILSTRIP/FEDSTRIP  item,  the  performance  record 
to  be  updated  is  defined  by  the  PR,  GBL,  and 
MILSTRIP/FEDSTRIP  number  and  Suffix  entered  on  the  template. 
For  the  cancelled  check  transaction,  the  record  must  exist 
and  be  open.  The  cancelled  check  amount  must  be  calculated 
from  the  disbursement  transaction  or  transactions  as  the 
amount  for  which  the  check  was  originally  written.  This 
cancelled  check  amount  must  update  the  cancelled  check 
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amount  from  the  performance  record.  The  voucher  number  from 
the  template  must  update  the  voucher  number  of  the  cancelled 
check  from  the  record. 

If  the  cancelled  check  is  for  a contract  or  grant,  the 
transaction  must  be  entered  at  the  PR  level.  The  contract 
record  to  be  updated  is  defined  by  the  contract  or  grant 
number  entered  on  the  template  and  the  performance  record  by 
the  PR  Number  and  Suffix  entered  on  the  template.  For  the 
cancelled  check  transaction,  both  records  must  exist  and  be 
open.  The  cancelled  check  amount  as  calculated  must  update 
the  cancelled  check  amount  from  the  contract  record  and  from 
the  performance  record.  The  voucher  number  from  the 
template  must  update  the  voucher  number  of  the  cancelled 
check  from  each  record. 

The  disbursement  transaction  or  transactions  and  the 
adjustment  transaction  or  transactions  entered  with  the 
cancelled  check  transaction  must  be  processed  as  normal 
negative  transactions.  Each  amount  from  the  template  must 
update  the  appropriate  amount  or  amounts  from  the  contract 
record  and  from  the  performance  record  and  must  satisfy  the 
normal  processing  edits  for  negative  amounts. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 

Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  cancelled  check 
process. 
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The 


2.10.1.10  Miscellaneous disbursement . 

miscellaneous  disbursement  process  inputs  and  records  the 
disbursement  for  such  payments  as  the  petty  cash  payments 
made  by  the  Fund  Control  Unit.  The  disbursement  is  entered 
at  the  PE  level  with  the  disbursement  being  applied  to  the 
specific  PR  indicated  on  the  template. 

The  miscellaneous  disbursement  process  consists  of  a 
disbursement  transaction,  an  update  transaction,  a 
correction  transaction,  a reopening  transaction,  and  a 
cancelled  check  transaction  defined  as  follows: 

• Disbursement  - a transaction  that  records  the 
commitment,  obligation,  cost,  and  disbursement. 

• Update  - a transaction  that  updates  the  commitment, 
obligation,  cost,  and  disbursement.  The  transaction 
must  have  been  directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  disbursement  or  the 
update  transaction. 

• Reopening  - a transaction  that  reopens  a PR  that  was 
closed  during  the  current  year. 

• Cancelled  check  - a transaction  that  records  the 
cancellation  of  a check  and  the  reversal  of  the 
original  disbursement. 

The  input,  processing,  and  output  requirements  for  the 
disbursement  transaction,  the  update  transaction,  and  the 
correction  transaction  are  discussed  in  the  following 
paragraphs.  The  requirements  for  the  reopening  transaction 
are  discussed  in  section  2.10,1.8.  The  requirements  for  the 
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cancelled  check  transaction  are  discussed  in 
2.  10. 1.9. 


section 


Input  - Figure  2. 10-31  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
miscellaneous  disbursement  process.  Figure  2.10-32  defines 
the  template  reguired  for  input  of  these  data  elements. 

The  disbursement  transaction  is  specified  by  the  entry 
of  commitment/obligation/cost/disbursement  dollars;  the 
amount  entered  must  be  positive.  The  update  transaction  is 
specified  by  the  update  indicator  and  the  entry  of 
commitment/obligation/cost/disbursement  dollars;  the  amount 
entered  may  be  either  positive  or  negative.  The  correction 
transaction  is  specified  by  the  correction  indicator;  any 
data  elements  that  are  incorrect  may  be  entered.  Both  an 
update  transaction  and  a correction  transaction  may  not  be 
entered  at  the  same  time. 


Processing  - The  specific  transaction  requirements  are 
discussed  by  transaction  in  the  following  paragraphs. 

Disbursemen t 


The  disbursement  transaction  inputs  and  records 
commitment,  obligation,  cost,  and  disbursement.  Each 
transaction  must  create  a performance  record. 


The  performance  record  to  be  created  is  defined. by  the 
PR  Number  and  Suffix  entered  on  the  template.  For  the 
disbursement  transaction,  the  record  must  not  exist.  The 
record  must  be  created  with  the  order  number,  the  voucher 


2.  10-117 


Data 

element 

Element 

required 

Source 

Error 

Input/Edit  requirements 

Error 

code 

1 As  of' 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B100 

B101 

Purchase 

Beguest 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  disbursement,  update,  and  correction 
transactions.  Position  1 must  be  alphanumeric. 
Positions  2 through  8 must  be  numeric.  Position  9 
must  ’^e  alphabetic  or  blank. 

B300 

B301 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement,  update,  and  correction 
transactions  when  the  suffix  is  other  than  the  base 
Suffix.  Must  be  numeric. 

B311 

Order  number 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Positions  1 and  2 must  be  a 
valid  T-order  prefix. 

B360 

B361 

Commitment, 
Obligation, 
Cost,  and 
Disbursement 
Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  For  a disbursement  transaction,  must  be 
numeric  and  greater  than  0.  For  an  update  correc- 
tion transaction,  must  be  numeric  and  not  egual  to 
0. 

B670 

B671 

B672 

B673 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  and  update  transactions 
and  for  the  correction  transaction  when  it  is  to  be 
corrected.  Position  1 mast  be  J , and  positions  2 
through  4 must  be  numeric,  or  all  must  be  numeric. 

B930 

B931 

Name  code 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  numeric- 

B400 

Method  of 
Authority 

Conditional 

User  supplied 

Fatal 

input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  MA  but  not  97. 

B100 

Bill 

B115 

Program  Year 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  PY.  Also 
validated  with  FS. 

B120 
B 1 21 
C500 
C508 

Fund  Source 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  FS.  Also 
validated  with  PY. 

B130 
B 1 39 
C500 
C506 
C507 

C5O0 

C509 

C510 


Figure  2.10-31.  - Miscellaneous  Disbursement  input  and  edit  requirements. 
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Data 

Element 

Error 

Error 

element 

required 

Source 

type 

Input/Edit  requirements 

code 

Primary  Work 
Code 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  nine  digits  and  a 
valid  PWC. 

B170 

B171 

B174 

Object  Class 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  Object  Class. 

B190 
B19 1 

Responsible 

Organization 

Conditional 

User  supplieu 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  RO. 

B200 
B20 1 

Performing 

Organization 

Conditional 

User  supplied 

Fatal 

Input  for  all  disbursement  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  Performing 
Organization. 

B320 

B321 

Primary  Job 
Code 

Conditional 

User  supplied 

Fatal 

Input  for  disburseaen  transactions  when  available 
and  for  the  update  and  correction  transactions  when 
it  is  to  be  updated  or  corrected.  If  the  first  po- 
sition is  0 or  1,  must  be  a Centerwide  Job  Code  and 
must  be  validated  with  FS  and  Performing  Organization. 

B330 

B331 

C506 

C509 

Secondary 
Job  Cod£ 

Conditional 

User  supplied 

Fatal 

Input  for  disbursement  transactions  when  available 
and  for  the  update  and  correction  transactions  where 
it  is  to  be  corrected.  If  the  first  position  is  0 
or  1,  must  be  a Centerwide  Job  Code  and  must  be  val- 
idated with  FS  ana  Performing  Organization. 

C340 

B341 

B342 

C507 

C510 

Reopening 

No 

None 

None 

Must  not  be  input. 

None 

Cancelled 

check 

No 

None 

None 

Must  not  fje  input. 

None 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  an  update.  Input  only  when  the  transaction  is  an 
update.  Both  the  update  transaction  and  the  correc- 
tion transaction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction  is 
a correction.  Beth  the  update  transaction  and  the 
correction  transaction  oust  not  be  specified. 

B062 

Figure  2.10-31.  - Miscellaneous  Disbursement  input  and  edit  requirements  (concluded). 


♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO*  MC  - MISCELLANEOUS  DISBURSEMENT 

PURCHASE  REQUEST  NO.  SUFFIX  ORDER  NO.  

C/O/C/D  $ , , . ± VOUCHER  NO.  NAME  CODE 

MA PY FS PNC OBJECT  CLASS RESP  ORG 

PERF  ORG PRIMARY  JOB  CODE  SECONDARY  JOB  CODE 

REOPENING  _ CANCELLED  CHECK 

FOR  CHANGES  ONLY:  UPDATE  CORRECTION 


Figure  2.10-32.  - Miscellaneous  Disbursement  template. 


number,  and  the  accounting  information  from  the  template  and 
with  commitment/obligation/cost/disbursement  dollars  from 
the  template  as  the  commitment,  obligation,  cost,  and 
disbursement.  The  funds  must  be  obtained  from  the  PEA 
account  specified  by  the  accounting  information.  The 
balance  of  the  PWA  accounts  must  be  sufficient. 

Update  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are- made 
to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Performance  records  must  be 
updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  may  be  either  positive  or  negative.  Amounts  from 
the  performance  records  must  be  increased  or  reduced.  The 
normal  processing  edits  must  be  satisfied;  in  addition,  a 
negative  update  or  correction  must  not  reduce  any  of  the 
amounts  below  0.  For  the  miscellaneous  disbursement 
process,  the  only  dollar  data  element  is 
commitmemt/obligation/cost/disbursement  dollars.  The 
processing  requirements  for  the  correction  of  information 
data  elements  specify  that  the  new  value  of  the  element  be 
overlaid  on  the  old.  The  information  data  elements  are 
order  number.  Voucher  number,  name  code.  Performing 
Organization,  Primary  Job  Code,  and  Secondary  Job  Code.  The 
processing  requirements  for  the  update  or  correction  of 
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control  data  elements  depend  on  the  specific  element.  If 
the  PE  Number  and  Suffix  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
If  HA,  PY,  FS,  PWC,  Object  Class,  or  RO  are  entered 
incorrectly,  the  requirements  are  those  of  an  accounting 
data  change  in  the  purchase  request  process  in  section 
2.6. 1.1.  The  system  must  reverse  the • incorrect  transaction 
and  generate  a new  transaction.  The  funds  must  be  returned 
to  the  PWA  account  defined  by  the  incorrect  accounting 
information  and  must  be  obtained  from  the  PWA  account 
defined  by  the  new  accounting  information.  The  issues  and 
the  balance  of  the  PWA  accounts  must  be  sufficient. 

In  addition,  the  update  transaction  must  update  the 
voucher  number.  The  voucher  number  from  the  template  must 
be  overlaid  on  the  voucher  number  from  the  performance 
record.  Only  the  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output.  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  miscellaneous 
disbursement  process. 

2.10.1.11  HILSTRIP/FEDSTRIP obligation . The 

HILSTRIP/FEDSTRIP  obligation  process  inputs  and  records  the 
commitment  and  the  obligation  for  HILSTRIP/FEDSTRIP  items. 
The  original  transactions  are  provided  by  the  Supply  system; 
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any  modifications  to  the  information  recorded  as  a result  of 
these  transactions  are  input  through  IFMS.  Section  2.17.1.2 
discusses  the  Supply  system  interface. 

The  MILSTRIP/FEDSTRIP  obligation  process  consists  of  an 
obligation  transaction,  an  update  transaction,  and  a 
correction  transaction  defined  as  follows: 

• Obligation  - a transaction  that  records  the 
commitment  and  the  obligation. 

• Update  - a transaction  that  updated  the  commitment 
and  the  obligation.  The  transaction  must  have'  been 
directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  obligation  or  the 
update  transaction. 

The  input,  processing,  and  output  requirements  for 
these  transactions  are  discussed  in  the  following  sections. 

Input  - Figure  2. 10-33  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
MILSTRIP/FEDSTRIP  obligation  process  with  template  input. 
Figure  2.10-34  defines  the  template  required  for  input  of 
these  data  elements.  Figure  2.10-35  contains  a list  of  data 
elements  that  must  be  input  and  edits  that  must  be  performed 
for  the  MILSTRIP/FEDSTRIP  obligation  process  with  interface 
input. 

On  the  template,  the  obligation  transaction  is 
specified  by  the  entry  of  commitment/obligation  dollars;  the 
amount  entered  must  be  positive.  The  update  transaction  is 


Data  Element 

element  required  Source 


Error 

type 


Input/Edit  requirements 


Error 

code 


1 As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 

and  conform  to  all  normal  date  edits. 

MILSTRIP/ 

FEDSTRIP 

number 

Yes 

User  supplied 

Fatal 

Input  for  all  obligation,  update,  and  correction 
transactions.  Must  be  numeric. 

Suffix 

Conditional 

User  supplied 

Fatal 

Input  for  obligation,  update,  and  correction  trans-^ 
actions  when  the  suffix  is  other  than  the  base  Suffix. 
Must  be  numeric. 

Commitment/ 

Obligation 

Dollars 

Conditional 

User  supplied 

Fatal 

Input  for  all  obligation  and  update  transactions  and 
for  the  correction  transaction  when  it  is  tc  be  cor- 
rected. For  an  obligation  transaction,  must  be 
numeric  and  greater  than  0.  For  an  update  or  cor- 
rection transaction,  must  be  numeric  and  not  equal 
to  0 . 

Method  of 
Authority 

Conditional 

User  supplied 

Fatal 

Input  for  all  obligation  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  MA  but  not  97. 

Program  Year 

Conditional 

User  supplied 

Fatal 

Input  for  all  obligation  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  ne 
updated  or  corrected.  Must  be  a valid  PY.  Also 
validated  with  FS. 

Fund  Source 

Conditional 

User  supplied 

Fatal 

Input  for  all  obligation  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  FS.  Also 

validated  with  PY. 


Primary  Work  Conditional  User  supplied  Fatal 

Code 


Object  Class  Conditional  User  supplied 


Input  for  all  obligation  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Bust  be  nine  digits  and  a 
valid  PWC. 

Input  for  all  obligation  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  Object  Class. 


B100 

B101 


B870 

B871 


B311 


B650 

B651 

B652 

B753 


B100 
Bill 
B 1 1 5 

B 1 20 
B121 
C500 
C508 

B 130 
B139 
C500 
C506 
C507 
C508 
C509 
C510 

B 170 
B 171 
B174 


B190 

B191 


Figure  2.10-33. 


- HILSTHIP/FEDSTRIE  Obligation  input  and  adit  cequiEements  (te.plate  input) . 
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Data 

element 

Element 

required 

Conditional 

Source 

Error 

iipe 

Fatal 

Input/Edit  requirements 

Responsible 

Organization 

User  supplied 

Input  for  all  obligation  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  RO. 

Performing 

Organization 

Conditional 

User  supplied 

Fatal 

Input  for  all  obligation  transactions  and  for  the 
update  and  correction  transactions  when  it  is  to  be 
updated  or  corrected.  Must  be  a valid  Performing 
Organization. 

Primary  Job 
Code 

Conditional 

User  supplied 

Fatal 

Input  for  obligation  transactions  when  available 
and  for  the  update  and  correction  transactions 
when  it  is  to  he  updated  or  corrected.  If  the 
first  position  is  0 or  1,  must  be  a Centerwide  Job 
Code  and  must  be  validated  with  FS  and  Performing 
Organization. 

Secondary 
Job  Code 

Conditional 

User  supplied 

Fatal 

Input  for  obligation  transactions  when  available 
and  for  the  update  and  correction  transactions  when 
it  is  to  be  updated  or  corrected.  If  the  first  posi- 
tion is  0 or  1,  must  be  a Centerwide  Job  Code  and 
must  be  validated  with  FS  and  Performing  Organization. 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  an  update.  Input  only  when  the  transaction  is  an 
update.  Both  the  update  transaction  and  the  correc- 
tion transaction  must  not  be  specified. 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  transaction 
is  a correction.  Input  only  when  the  transaction  is 
a correction.  Both  the  update  transaction  and  the 
correction  transaction  must  not  be  specified. 

2 9 

hr! 

T)  Q 
81 

eg 

|s 

Figure  2.10-33.  - MILSTR IP/FED STB IP  Obligation  input  and  edit  requirements  (template  input)  (concluded) . 


Error 

code 


B200 

B201 


B320 

B321 


B330 

B331 

C506 

C509 


B340 
B341 
B342 
C507 
C51 0 

B062 


B062 


****IFMS  SEPTEMBER  30,  197«  AS  OF  , / / 

****TEMPLATE  NO.  MD  - MILSTRIP/FEDSTRIP  OBLIGATION 

MILSTRIP/FEDSTRIP  NO.  SUFFIX  

C/O  $_, , , 

MA PY FS  PNC OBJECT  CLASS 

PERF  ORG  PRIMARY  JOB  CODE  SECONDARY  JOB  CODE 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


RESP 


Figure  2. 10-34 


MILSTRIP/FEDSTRIP  Obligation  template 


Z.Zl~Ol 


/• 


Data 

element 

Element 

required 

Source 

Error 

Input/Edit  requirements 

BILSTRIP/ 

FEDSTRIP 

number 

Yes 

Interface 

Fatal 

Input  for  all  transactions. 

Bust  be  numeric. 

Suffix 

Yes 

Interface 

Fatal 

Input  for  all  transactions. 

Bust  be  numeric. 

Commitment/ 

Obligation 

Dollars 

Yes 

Interface 

Fatal 

Input  for  all  transactions, 
greater  than  0- 

Bust  be  numeric  and 

Bethod  of 
Authority 

Yes 

Interface 

Fatal 

Input  for  all  transactions, 
but  not  97. 

Bust  be  a valid  BA 

Program  Year 

Yes 

Interface 

Fatal 

Input  for  all  transactions. 
Also  validated  with  FS. 

Bust  be  a valid  PY. 

Fund  Source 

Yes 

Interface 

Fatal 

Input  for  all  transactions. 
Also  validated  with  PY. 

Bust  be  a valid  FS. 

Primary  Work 
Code 

Yes 

Interface 

Fatal 

Input  for  all  transactions, 
and  a valid  PWC- 

Bust  be  nine  digits 

Object  Class 

Yes 

Interface 

Fatal 

Input  for  all  transactions. 
jeGt  Class. 

Bust  be  a valid  Ob- 

Responsible 

Organization 

Yes 

Interface 

Fatal 

luput  for  all  transactions. 

Bust  be  a valid  HO. 

Performing 

Organization 

Yes 

Interface 

Fatal 

Input  for  all  transactions, 
forming  Organization. 

Bust  be  a valid  Per- 

Primary  Job 
Code 

Yes 

Interface 

Fatal 

Input  for  transactions  when  available.  If  the 
first  position  is  0 or  1,  must  be  a Centerwide  Job 
Code  and  must  be  validated  with  FS  and  Performing 
Organization. 

Secondary  Job 
Code 

Yes 

Interface 

Fatal 

Input  for  transactions  when  available.  If  the 
first  position  is  0 or  1,  must  be  a Centerwide  Job 
Code  and  must  be  validated  with  FS  and  Performing 
Organization. 

Error 

code 


B870 

B871 


B310 
B31 1 

B600 

B601 

B604 

B110 

Bill 

B115 

B120 

B121 

C500 

B130 

B139 

C500 

C506 

C507 

B170 

B171 

B174 

B190 

B191 

B200 

B201 

B320 

B321 

B330 

B331 

B506 


B340 

B341 

B342 

C507 


Figure  2, 10-35,  - BILSTRIP/FEDS1RIP  Obligation  input  and  edit  requirements  (interface  input) 


specified  by  the  update  indicator  and  the  entry  of 
commitment/obligation  dollars;  the  amount  entered  may  be 
either  positive  or  negative.  The  correction  transaction  is 
specified  by  the  correctiom  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Both  an  update 
transaction  and  correction  transaction  may  not  be  entered  at 
the  same  time.  On  the  interface,  only  obligation 
transactions  may  be  entered. 

Processing  - The  specific  transaction  requirements  are 
discussed  by  transaction  in  the  following  paragraphs. 

Obligation 

The  obligation  transaction  inputs  and  records  the 
commitment  and  obligation.  Each  transaction  must  create  a 
performance  record. 

The  performance  record  to  be  created  is  defined  by  the 
MILS TRIP/FED STRIP  number  and  Suffix  entered  on  the  template 
or  from  the  interface.  For  the  obligation  transaction,  the 
record  must  not  exist.  The  record  must  be  created  with  the 
accounting  information  from  the  template  or  interface  and 
with  commitment/obligation  dollars  from  the  template  or 
interface  as  the  commitment  and  the  obligation.  The  balance 
of  the  PWA  account  must  be  sufficient. 

Qpdate  and  Correction 

The  update  and  correction  transactions  input  and  record 
updates  and  corrections.  Updates  are  made  to  either  dollar 
data  elements  or  control  data  elements;  corrections  are  made 
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to  either  dollar  data  elements,  information  data  elements, 
or  control  data  elements.  Performance  records  must  be 
updated  or  corrected  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  may  be  either  positive  or  negative.  Amounts  from 
the  performance  records  must  be  increased  or  reduced.  The 
normal  processing  edits  must  be  satisfied;  in  addition,  a 
negative  update  or  correction  must  not  reduce  any  of  the 
amounts  below  0.  For  the  MILSTRIP/FEDSTRIP  obligation 
process,  the  only  dollar  data  element  is 
commitment/obligation  dollars.  The  processing  requirements 
foJ-  the  correction  of  information  data  elements  specify  that 
the  new  value  of  the  element  be  overlaid  on  the  old.  The 
information  data  elements  are  Performing  Organization, 
Primary  Job  Code,  and  Secondary  Job  Code.  The  processing 
requirements  for  the  update  or  correction  of  control  data 
elements  depend  on  the  specific  element.  If  the 
MILSTRIP/FEDSTRIP  number  and  Suffix  are  entered  incorrectly, 
the  transaction  must  be  reversed  and  a new  transaction 
entered.  If  MA,  PY,  FS,  PWC,  object  class,  or  RO  are 
entered  incorrectly,  the  requirements  are  those  of  an 
accounting  data  change  in  the  Purchase  Request  process  in 
section  2.6. 1.1.  The  system  must  reverse  the  incorrect 
transaction  and  generate  a new  transaction.  The  funds  must 
be  returned  to  the  PWA  account  defined  by  the  incorrect 
accounting  information  and  must  be  obtained  from  the  PWA 
account  defined  by  the  new  accounting  information.  The 
issues  and  the  balance  of  the  PWA  accounts  must  be 
sufficient. 
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To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 

Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.10.2  discusses  the  standard  online 
responses  and  error  messages  * required  in  the 
MILSTRIP/FEDSTRIP  obligation  process. 

2.10.2  Output  Message  Requirements 

Figures  2.10-36  through  2.10-40  contain  a list  of 
output  message  requirements.  Figure  2.10-41  contains  a 
correlation  of  output  messages  by  transaction. 

2.10.3  Inquiry  Requirements  j 

X : j 

Figure  2. 10-42  contains  a list  of  inquiry  input  data  I 

elements  and  response  data  elements  required  for  the  | 

disbursement  process.  'j 

• i 

' ^ 

j 

2.10.4  Report  Requirements  i 

i 

. 

1 

Section  2.19  lists  the  disbursement  report  j 

requirements.  The  following  reports  reflect  disbursement  I 

. . i 

activity:  j 

i 

1 

A 

• Open  Commercial  Order  Status 
Part  I - Contracts 
Part  II  - Grants 

Part  III  - Letter  of  Credit  -t 


Code 


Message 


****  DISBURSEMENT  TRANSACTION  - CONTRACT 

****  DISBURSEMENT  TRANSACTION  - GRANT 

****  DISBURSEMENT  TRANSACTION  - LETTER  OF  CREDIT  ISSUANCE 

****  DISBURSEMENT  TRANSACTION  - LETTER  OF  CREDIT  WITHDRAWAL 

****  DISBURSEMENT  TRANSACTION  - LETTER  OF  CREDIT  DISBURSEMENT 

****  DISBURSEMENT  TRANSACTION  - T-ORDER 

****  DISBURSEMENT  TRANSACTION  - GBL 

****  DISBURSEMENT  TRANSACTION  - MILS TRIP/FEDST RIP 

****  DISBURSEMENT  TRANSACTION  - COSTING 

****  DISBURSEMENT  TRANSACTION  - PRIOR  YEAR  REOPENING 

****  DISBURSEMENT  TRANSACTION  - MISCELLANEOUS  DISBURSEMENT 

B0 1 0 TYPE  OF  TRANSACTION  NOT  SPECIFIED 

B0 1 2 INVALID  TRANSACTION  SPECIFIED 

B062  BOTH  'UPDATE'  AND  'CORRECTION*  MUST  NOT  BE  SPECIFIED 

C440  EXTENT  OF  PAYMENT  NOT  SPECIFIED 

C44 1 MULTIPLE  EXTENT  OF  PAYMENTS  SPECIFIED 


Figure  2.10-36.  - Disbursement  transaction-begun  messages. 
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Code 


Message 


A000  Processing  Complete 


Figure  2.10-37.  - Disbursement 
transaction-complete  messages. 
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Code  Message 

B080  'COMPLETE  PAYMENT'  MUST  NOT  BE  SPECIFIED 
B 081  'FINAL  PAYMENT'  MUST  NOT  BE  SPECIFIED 

B082  'FINAL  COSTING*  MUST  NOT  BE  SPECIFIED 

B100  'AS  OF'  DATE  INVALID 

B 1 01  'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE 

B 1 1 0 MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 1 5 MA  MUST  NOT  BE  97 

B 1 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

B130  FS  NOT  ENTERED 

B 1 39  FS  INVALID 

B170  PWC  NOT  ENTERED 

B 171  PNC  INVALID 

B 17 4 PNC  MUST  BE  9 DIGITS 

B 1 90  OBJECT  CLASS  NOT  ENTERED 

B191  OBJECT  CLASS  INVALID 

B200  RESPONSIBLE  ORGANIZATION  NOT  ENTERED 

B201  RESPONSIBLE  ORGANIZATION  INVALID 

B300  PURCHASE  REQUEST  NUMBER  NOT  ENTERED 

B301  PURCHASE  REQUEST  NUMBER  INVALID 

B310  SUFFIX  NOT  ENTERED 

B311  SUFFIX  INVALID 

B320  PERFORMING  ORGANISATION  NOT  ENTERED 

B321  PERFORMING  ORGANIZATION  INVALID 

B330  PRIMARY  JOB  CODE  INVALID 

B33 1 PRIMARY  JOB  CODE  MUST  BE  CENTERNIDE  JOB  CODE 

B340  SECONDARY  JOB  CODE  INVALID 

B341  SECONDARY  JOB  CODE  RUST  BE  BLANK 

B342  SECONDARY  JOB  CODE  MUST  BE  CENTERNIDE  JOB  CODE 

B360  CONTRACT/ORDER  HUMBER  NOT  ENTERED 

B361  CONTRACT/ORDER  NUMBER  INVALID 

B370  CONTRACT  AMENDMENT  NUMBER  INVALID 

B380  CONTRACT  SCHEDULE  NUMBER  INVALID 


Figure  2.10-38.  - Disbursement  data  element 
edit  error  messages. 
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Code 

Message 

B381 

CONTRACT  SCHEDULE  NUMBER  MUST  BE 

BLANK 

B400 

CONTRACTOR  NAME  CODE  INVALID 

B420 

GBL  NUMBER  NOT  ENTERED 

B421 

GBL  NUMBER  INVALID 

B600 

$ AMOUNT  NOT  ENTERED 

B601 

$ AMOUNT  INVALID 

B602 

$ AMOUNT  MUST  NOT  BE  ZERO 

B604 

$ AMOUNT  MUST  BE  GREATER  THAN  ZERO 

B630 

COST  $ NOT  ENTERED 

B631 

COST  $ INVALID 

B632 

COST  $ MUST  NOT  BE  ZERO 

B633 

COST  $ MUST  BE  GREATER  THAN  ZERO 

B651 

C/O  $ INVALID 

B652 

C/O  $ MUST  NOT  BE  ZERO 

B653 

C/O  $ MUST  BE  GREATER  THAN  ZERO 

C656 

C/O  $ MUST  HAVE  THE  SAME  SIGN  AS 

COST  $ 

B66 1 

C/O/C  $ INVALID 

B662 

C/ O/C  $ MUST  NOT  BE  ZERO 

B670 

C/O/C/D  $ NOT  ENTERED 

B671 

C/O/C/D  $ INVALID 

B672 

C/O/C/D  $ MUST  NOT  BE  ZERO 

B673 

C/O/C/D  $ MUST  BE  GREATER  THAN  ZERO 

B700 

DISBURSEMENT  $ NOT  ENTERED 

B701 

DISBURSEMENT  $ INVALID 

B702 

DISBURSEMENT  $ MUST  NOT  BE  ZERO 

B703 

DISBURSEMENT  $ MUST  BE  GREATER  THAN  ZERO 

B711 

DISCOUNT  $ INVALID 

B712 

DISCOUNT  $ MUST  BE  ZERO 

B713 

DISCOUNT  $ MUST  BE  GREATER  THAN 

ZERO 

B721 

WITHHOLDING  $ INVALID 

B722 

WITHHOLDING  $ MUST  NOT  BE  ZERO 

B731 

DEPOSIT  ON  CONTAINERS  $ INVALID 

Figure  2,10-38.  - Disbursement  data  element 
edit  error  messages  (continued)  . 
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Code 


' Message 


B732  DEPOSIT  ON  CONTAINERS  $ MOST  NOT  BE  ZERO 

B733  DEPOSIT  ON  CONTAINERS  $ MOST  BE  GREATER  THAN  ZERO 

B741  PAYMENT  BY  OTHERS  $ INVALID 

B742  PAYMENT  BY  OTHERS  $ MOST  NOT  BE  ZERO 

B743  PAYMENT  BY  OTHERS  $ MOST  BE  GREATER  THAN  ZERO 

B751  ADVANCE  ESTABLISHED  INVALID 

B752  ADVANCE  ESTABLISHED  $ MOST  NOT  BE  ZERO 

B753  ADVANCE  ESTABLISHED  $ MOST  BE  GREATER  THAN  ZERO 

B761  ADVANCE  LI QOI DATED  $ INVALID 

2762  ADVANCE  LIQUIDATED  $ MOST  NOT  BE  ZERO 

B763  ADVANCE  LIQOIDATED  $ MOST  BE  GREATER  THAN  ZERO 

B770  REOPENING  $ NOT  ENTERED 

B771  REOPENING  $ INVALID 

B772  REOPENING  $ MUST  NOT  BE  ZERO 

B773  REOPENING  $ MUST  BE  GREATER  THAN  ZERO 

B800  GRANT  NUMBER  NOT  ENTERED 

B801  GRANT  NUMBER  INVALID 

B810  LETTER  OF  CREDIT  NOMBER  NOT  ENTERED 

B811  LETTER  OF  CREDIT  NOMBER  INVALID 

B830  LETTER  OF  CREDIT  VOUCHER  NUMBER  NOT  ENTERED 

B821  LETTER  OF  CREDIT  VOUCHER  NUMBER  INVALID 

B822  LETTER  OF  CREDIT  VOUCHER  NUMBER  MUST  NOT  BE  LESS  THAN  ZERO 

B830  SERIAL  NUMBER  NOT  ENTERED 

B831  SERIAL  NUMBER  INVALID 

B832  SERIAL  NUMBER  MUST  NOT  BE  LESS  THAN  ZERO 

B840  DISCOUNT  OVERRIDE  MUST  BE  BLANK 

B860  CONTRACT/GRANT  NUMBER  NOT  ENTERED 

B861  CONTRACT/GRAND  NUMBER  INVALID 

B870  MILSTR IP/FEDS TRIP  NJMBER  NOT  ENTERED 

B871  MILSTR IP/FEDSTR IP  NUMBER  INVALID 

B880  CONTRACT  TYPE  NOT  ENTERED 

B881  CONTRACT  TYPE  INVALID 

B930  VOUCHER  NUMBER  NOT  ENTERED 

B931  VOUCHER  NUMBER  INVALID 


Figure  2.10-38.  - Disbursement  data  element 
edit  error  messages  (continued)  . 
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Code  Message 

C450  BOTH  'CANCELLED  CHECK'  AND  'REOPENING'  MOST  NOT  BE  SPECIFIED 
C500  PY  FS  COMBINATION  INVALID 

C 506  FS,  PERF  ORG,  PRIMARY  JOB  CODE  COMBINATION  INVALID 
C507  FS,  PERF  ORG,  SECONDARY  JOB  CODE  COMBINATION  INVALID 
C508  PY  FS  COMBINATION  INVALID 

C509  FS , PERF  CBG PRIMARY  JOB  CODE COMBINATION  INVALID 

C510  FS  , PERF  ORG  SECONDARY  JOB  CODE  COMBINATION  INVALID 


Figure  2.10-38,  - Disbursement  data  element 
edit  error  messages  (concluded) . 
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Code 


Message 


A220  ADDITIONAL  COMMITMENT  $ OBTAINED  FROM  PWA  ACCOUNT 

PURCHASE  REQUEST  NO.  SUFFIX 

ADDITIONAL  , , . 


Figure  2. 10-39 


Disbursement  advisory  messages 


Code  Message 

D142  PHA  ISSUES  INSUFFICIENT 

MA PY FS HO PNC 

OBJECT  CLASS  CARRIER  ID  SUB  ID 

ISSUES  , , . UPDATE  , , . - 

D1 43  PHA  BALANCE  INSUFFICIENT  TO  INCREASE  ISSUES 

MA PY FS RO PHC 

OBJECT  CLASS  CARRIER  ID SUB  ID 

BALANCE  , , . UPDATE  , , . - 

ADDITIONAL  $ EXCEED  LIMIT 

PURCHASE  REQUEST  NO.  SUFFIX  

D144  OBLIGATION  $ EXCEED  COMMITMENT  $ 

ADDITIONAL  $ EXCEED  LIMIT 

PURCHASE  REQUEST  NO.  SUFFIX  

OBLIGATION  $_, , , . COMMITMENT  $_, , , ._ 

ADDITIONAL  $_, , , . LIMIT  $_, , , . 

D 1 80  PERFORMANCE  DATA  RECORD  NOT  FOUND 

PURCHASE  REQUEST  NO.  SUFFIX  

D181  PERFORMANCE  DATA  RECORD  ALREADY  EXISTS 

PURCHASE  REQUEST  NO.  SUFFIX  

D 1 86  PERFORMANCE  DATA  RECORD  CLOSED 

PURCHASE  REQUEST  NO.  SUFFIX  

D192  CONTRACT  RECORD  NOT  FOUND 

CONTRACT/ORDER  NO.  

D 197  CONTRACT  RECORD  CLOSED 

CONTRACT/ORDER  NO.  

D300  ADVANCE  ESTABLISHED  $ EXCEED  OBLIGATION  $ 

CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

ESTABLISHED  , , . UPDATE  , . ± 

OBLIGATION  , , . UPDATE  , , . ± 

D302  ADVANCE  LIQUIDATED  $ EXCEED  ADVANCE  ESTABLISHED  $ 
CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

LIQUIDATED  $_, , , . UPDATE  , , . 

ESTABLISHED  $_, , , . UPDATE  $_, , , ■ ± 


Figure  2.10-40.  - Disbursement  processing  error  messages. 


Code  Message 

D303  COST  $ EXCEED  OBLIGATION  $ 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

COST  $_, , , . UPDATE  , , . ± 

OBLIGATION  $_, , , . UPDATE  , , . ± 

D304  DISBURSEMENT  $ EXCEED  COST  $ 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

DISBURSEMENT  , , . UPDATE  $_, , , . ± 

COST  , , . UPDATE  , , . ± 

D305  DISBURSEMENT  $ + WITHHOLDING  $ EXCEED  OBLIGATION  $ 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

DISBURSEMENT  , , . UPDATE  , , . ± 

WITHHOLDING  , , . UPDATE  $_, , , . ± 

OBLIGATION  $_, , , . UPDATE  $_, , . ± 

D306  COMMITMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 

PURCHASE  REQUEST  NO.  SUFFIX  

COMMITMENT  , , . UPDATE  $_, , , . - 

D307  OBLIGATION  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

OBLIGATION  , , . UPDATE  , , . - 

D308  COST  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

COST  $_, , , . UPDATE  $_, , , . - 

D309  DISBURSEMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

DISBURSEMENT  , , . UPDATE  $_, , . - 

D310  DISCOUNT  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  


Figure  2.10-40.  - Disbursement  processing 
error  messages  (continued) . 


2.10-139 


Code 


Message 


DISCOUNT  $_, , , . UPDATE  $_, , , • “ 

D311  WITHHOLDING  $ BUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDEB  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

WITHHOLDING  , , . UPDATE  $_, , , • - 

D312  DEPOSIT  ON  CONTAINERS  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDEB  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

DEPOSIT  , , . UPDATE  $_, , , . - 

D313  PAYMENT  BY  OTHERS  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDEB  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

PAYMENT  , , . UPDATE  , , . - 

D314  ADVANCE  ESTABLISHED  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

ESTABLISHED  , , . UPDATE  , , . - 

D 3 1 5 ADVANCE  LIQUIDATED  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDEB  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

LIQUIDATED  , . . . UPDATE  , , . - 

D316  DISBURSEMENT  $ ♦ WITHHOLDING  $ EXCEED  OBLIGATION  $ 

FOR  NON-EXCLUEED  OBJECT  CLASSES 

CONTRACT/ORDEB  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

DISBURSEMENT  $_, , , . UPDATE  , , ■ ± 

WITHHOLDING  , , . UPDATE  $_, , , . + 

OBLIGATION  $_, , , . UPDATE  , , . ± 

0317  DISBURSEMENT  $ + WITHHOLDING  $ EXCEED  COST  $ 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  BEQUEST  NO.  SUFFIX  

DISBURSEMENT  , , . UPDATE  $_, , , . ± 

WITHHOLDING  , , . UPDATE  , , - ± 

COST  $_, , , . UPDATE  , , • ± 


Figure  2.10-40.  - Disbursement  processing 
error  messages  (continued) . 


2. 10-140 


Code  Message 

0318  DISBURSEMENT  $ + WITHHOLDING  $ EXCEED  COST  $ 

FOR  NON-BXCLODED  OBJECT  CLASSES 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO. SUFFIX  __ 

DISBURSEMENT  , , • UPDATE  S_, , , • — ± 

WITHHOLDING  #_, , , • UPDATE  , , • — ± 

COST  , , . UPDATE  , / • ± 

0319  DISBURSEMENT  $ + UNLIQUIDATED  ADVANCE  S EXCEED  OBLIGATION  $ 


PURCHASE  REQUEST  NO. 

SUFFIX 

DISBURSEMENT  $_, 

t _ 

UPDATE  $ . . .....  ± 

ADVANCE  , r 

V • __ 

UPDATE  $_, , , • ± 

OBLIGATION  $ 

UPDATE  $ . . ......  . ....  ± 

D320 

COMPLETE  PAYMENT  MUST 

NOT 

BE  SPECIFIED 

PURCHASE  REQUEST  NO. 

SUFFIX 

ESTABLISHED  , 

LIQUIDATED  , . 

D321 

FINAL  PAYMENT  MUST  NOT 

BE 

SPECIFIED 

PURCHASE  REQUEST  NO. 

SUFFIX 

ESTABLISHED  , 

_ t 

LIQUIDATED  , , • 

D330  LETTER  OF  CREDIT  CONTROL  RECORD  NOT  FOUND 
LETTER  OF  CREDIT  NO.  


D331  LETTER  OF  CREDIT  CONTROL  RECORD  ALREADY  EXISTS 

LETTER  OF  CREDIT  NO.  

D332  LETTER  OF  CREDIT  NO.  PY  

LETTER  OF  CREDIT  NO. PY  

D334  LETTER  OF  CREDIT  WITHDRAWAL  RECORD  NOT  FOUND 

LETTER  OF  CREDIT  NO.  

D340  WITHDRAWAL  $ EXCEED  ISSUANCE  $ 

LETTER  OF  CREDIT  NO. PY 

WITHDRAWAL  $_, , , - UPDATE  » , • — ± 

ISSUANCE  . UPDATE  $_, , — ■ — ± 

D341  DISBURSEMENT  $ EXCEED  WITHDRAWAL  $ 

LETTER  OF  CREDIT  NO.  

DISBURSEMENT  , , • UPDATE  *_, , 

WITHDRAWAL  , _■ UPDATE  , , • — ± 


Figure  2.10-40.  - Disburseaent  processing 
error  aessages  (continued)  . 


Code  Message 

D342  ISSUANCE  S MUST  NOT  BE  LESS  THAN  ZERO 

LETTER  OF  CREDIT  NO. PY  

CONTRACT/GRANT  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

ISSUANCE  $_, UPDATE  , . - 

D343  WITHDRAWAL  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/GRANT  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

LETTER  OF  CREDIT  NO.  PY 

WITHDRAWAL  $_, , , : UPDATE  $_, , , . - 

D344  ISSUANCE  $ EXCEED  OBLIGATION  $ 

CONTRACT/GRANT  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO. SUFFIX 

ISSUANCE  , , .. UPDATE  , , . ± 

. OBLIGATION  , , . UPDATE  , , . ± 

D345  DISBURSEMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 
LETTER  OF  CREDIT  NO.  

DISBURSEMENT  , , . UPDATE  $_, , , 

D347  WITHDRAWAL  $ EXCEED  ISSUANCE  $ 

CONTRACT/GRANT  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

WITHDRAWAL  , , . UPDATE  , , . ± 

ISSUANCE  , , .__±  UPDATE  , , . 

D360  CONTRACT  RECORD  CURRENTLY  ACTIVE 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

D361  PURCHASE  REQUEST  RECORD  CURRENTLY  ACTIVE 

PURCHASE  REQUEST  NO.  SUFFIX  

D362  PAYMENT  BY  OTHERS  $ EXCEED  REOPENING  $ 

CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

PAYMENT  BY  OTHERS  $_, , , . REOPENING  

D530  ESTABLISHMENT  $ EXCEED  DISBURSEMENT  $ 

CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  


Figure  2.10-40.  - Disbursement  processing 
error  messages  (continued) . 


2.10-142 


Code 


Message 


ESTABLISHMENT  , UPDATE  , 

DISBURSEMENT  S_, , 'UPDATE  

D536  ESTABLISHMENT  S EXCEED  ADVANCED  ESTABLISHED  $ 
CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO. SUFFIX 

ESTABLISHMENT  S . . , UPDATE  , 

ADVANCE  $_, , UPDATE  


Figure  2.10-40.  - Disbursement  processing 
error  messages  (concluded) • 


2.10-143 


t?hl-Ot 


Message 


Transaction 

Contract  disbursement 
Disbursement 

Net  disbursement 

Desposit  on  containers 

Payment  by  others 

Payment  on  reimbursable  orders 

Discount 

Withholding 

Adjustment 

Commitment/Obligation 

Commitment/Obligation/Cost 

Cost 

Update 

Correction 

Current  year  reopening 
Cancelled  check 


Message 


Transaction 

Contract  disbursement 
Disbursement 
Net  disbursement 
Deposit  on  containers 
Payment  by  others 
Payment  on  reimbursable  orders 
Discount 
Withholding 

Adjustment 

Commitment/Obligation 

Commitment/Obligation/Cost 

Cost 

Update 

Correction 

Current  year  reopening 
Cancelled  check 


A A B B B B 
0 2 0 1 1 3 
0 2 6 0 0 0 
0 0 2 0 1 1 


X 

X 

X 

X 

X 

X 


bbbbbbebbbbbbbbb 

3333366666777777 

1 668833555000  11 

10  10112126123 


B B B B B 
7 7 8 9 9 
4 4 4 3 3 
2 3 0 0 1 


X 

X 

X X 
X 


C D D 

4 1 1 

5 4 4 

0 2 3 


X X 


D D 
1 1 
8 $ 
0 6 


X X 
X X 
X X 
X X 


D D D D 
3 3 3 3 
0 0 0 0 
5 6 7 8 


B B B B B B 

7 7 7 7 7 7 

1 2 2 3 3 3 4 

2 3 1 2 1 2 3 1 


D D 
3 3 

1 1 
3 6 


D D D D D 
3 3 3 3 5 
116  6 3 
7 8 0 1 0 


Figure  2. 1Q~41a.  - Disbursement  messages  by  transaction  - contract. 


x X X X x 


Transaction 


Message 


Grant  Disbursement 
Disburseaent 

Advance  established 
Advance  liquidated 

Adjustment 

Commitment/Obligation 

Cost 

Commitment/Obligation/Cost/ 

Update 

Correction 

Current  year  reopening 
Cancelled  check 


A A B B B B 
0 2 0 1 1 3 
0 2 6 0 0 0 
0 0 2 0 1 1 


B B B B 
3 6 6 6 
13  3 5 

112  1 


BBBBBBBBBBBBC 
6677777788994 
5 55  5566600335 
2612312301010 


Message 

Transaction 

Grant  Disburseaent 
Disbursement 

Advance  established 
Advance  liquidated 

Adjustment 

Commitment/Obligation 

Cost 

Coamitment/Obligat ion/Cost 
Update 
Correction 

Current  year  reopening 


DDDDDDDDDDDD  DDDDDDDDD 
1 111  111  3 3 333333333335 
444889900000000111663 
23406270  2 35678945701  6 


Cancelled  check 


Figure  2.10-41b.  - Disburseaent  messages  by  transaction  - grant 


x x x 


Message 

Transaction 

Letter  of  credit  disbursement 
Issuance 

Issuance  update 

Issuance  correction 

Withdrawal 

Withdrawal  update 

Withdrawal  correction 

Disbursement 

Adjustment 

Commitment/Obligation 

Cost 

Commitment/Obligation/Cost 

Update 

Correction 

Current  year  reopening 


AABBBBBBBB 

0201  133336 

0260001880 
0 0 2 0 1 1 1 0 1 0 

X xxxxxxx 

X xxxxxxxx 

X xxxxxx  x 

XXX  X 

X X X X x 

X XXX 

X X X X X X X 

XX  XXXXXX 

X XXXXXX 

XX  XXXX  XX 

X X XXXXXXX 

xxxxxxxxx 
x X X X X 


bbbbbbbbbb 
6666666677 
0003355500 
1 2 41  2 12601 

X X 

X X 
X X 
X X 

X X 
X X 

X X 

XXX 

X X 

X X X X X 

XXXXXXX 
X X X X*  x X 


Message 


Transaction 

Letter  of  credit  disbursement 
Issuance 

Issuance  update 

Issuance  correction 

Withdrawal 

Withdrawal  update 

withdrawal  correction 

Disbursement 

Adjustment 

Coamitment/Obligation 

Cost 

Commitment/Obligation/Cost 

Update 

Correction 

Current  year  reopening 


B B B B B B B 

7 7 8 8 8 6 8 

0 0 1 1 2 2 2 

2 3 0 1 0 1 2 

X X 
X X 
X X 

X X X X X 

X X X X X 

X X XX 

X 


X 

X 


B B B B B B 

8 8 8 8 8 9 

3 3 3 6 6 3 

0 12  0 10 

XXX 
XXX 
X X 

XXX  X 

XXX  x 

X X 

XXX 

X X 
X X 
« X X 

XXX 

X X 

X X 


B B B D D D D 

9 111111 

3 U 4 4 8 8 9 

1 2 3 4 0 6 2 

X XXX 

X XXX 

X XXX 

X 
X 
X 

X XXX 

XXXXXX 

XXX 

xxxxxxx 

xxxxxxx 

xxxxxxx 

X x 


Figure  2.10~41c 


- Disbursement  messages  by  transaction  - letter  of  credit 


Message 

Transaction 

Letter  of  credit  disbursement 
Issuance 

Issuance  update 

Issuance  correction 

Withdrawal 

Withdrawal  update 

Withdrawal  correction 

Disbursement 

Adjustment 

Commitment/Obligation 

Cost 

Commitment /Obligation/Cost 
Update 
Correction 

Current  year  reopening 


dddddddddddddddddddDd 
133333333333333333333 
9000000  13333444444466 

7356789701240123W5701 

x XXX  X 

x X X X X X X 

x X X X X X X 

X X 

X XXX 

x XXX 

XX  X X X X X 


X X X X X x x 

XX  XX 

XXXXXXX  x 

XXXXXXXXX  XXX  X X X X 

XXXXX  XXXX  XXX  xx^xx 

X X 


\\ 


Figure  2.10-41c.  - Disbursement  messages  by  transaction  - letter  of  credit  (concluded). 


10-1  as 


Transaction 


to 


Message  A A B B B B B B B 

0 2 0 0 1 1 3 3 3 

026800001 
002  00  10  1 1 


bbeb  bbbbbbb 
6 6 6 6 6 7 7 7 7 7 7 
33  5 5 50001  11 
1 2 1 2 6 1 2 3 1 2 3 


BBBBBBBBBBB 
77777777777 
33344455566 
1 2 3 1 2 3 1 2 3 1 2 


T-order  disbursement 
Disbursement 

Net  disbursement 

Deposit  on  containers 

Payaent  by  others 

Payaent  on  reimbursable  orders 

Advance  established 

Advance  liquidated 

Discount 

Adjustment 

Coaaitaent/Obligation 

Cost 

Coaaitment/Obligat ion/Cost 
Update 
Correction 

Current  year  reopening 
Cancelled  check 


6to  l -Oi 


Figure  2.10-41e,  - Disbursement  messages  by  transaction  - GBL. 


i 

K. 

f. 


^|V 


10-150 


Message 


w 


Transaction 


aab  bbbbbbbbb 
020000113366 
0 2 1 1 6 8 0 0 1 1 0 0 
0 00221010101 


bbbbbbbbb 
666666777 
033555000 
2121261231231 


MILS TRIP /FED STRIP  disbursement 
Disbursement 

Net  disbursement 
Advance  established 
Advance  liquidated 

Adjustment 

Commitment/Obligation 

Cost 

Co m mit me nt/Obli gat ion/Cost 
Update 
Correction 

Current  year  reopening 
Cancelled  check 


X X X X 
X X X X 
X XX 


X X X X X X X 

xxxxxxxx 

X X X X X X X 


X 


X 

X 


X 

X 


X X 
X 

X X 


XX  x 

XX  x 

XX  x 


X X 


X X X X X 


XX  X X x X X 


X 


XX  X 


XXX 

X X 

X X X X X 

xxxxxxx  XX 

xxxxxxx  XX 


Transaction 


Message  B B B B B B 

7 7 8 8 9 9 

6 6 7 7 3 3 

2 3 0 1 0 1 


CDDDDDDDD 

4 111113  3 3 

544488000 

023406234 


DDDDDDDDDD 
3333333335 
0000  11  1 2 63 
6789459110 


mtt.strtp  /FED  STRIP  disbursement 
Disbursement 

Het  disbursement 
Advance  established 
Advance  liquidated 


X X X X 

X X X X 


X X X X X 

X X X X 

X XXX 


X 

X 


Adjustment 

Commitment/Obligation 

Cost 

Co  orhitment/Obligat  ion/Cost 

Update 

Correction 

Current  year  reopening 


X x 
X X 
X X 

X X X 

X X 

X X 


X X X X X 

X X 

X X X X X 


X X X X 
XX  X 
X X X X X 


xxx  xxxxx  x x x xxxxx  X 

X X X X X X X X X X X X X X X X X 

X x 


•cancelled  check 


Figure  2.10-41f. 


Disbursement  messages  by  transaction  - HU.ST8IP/FEDSTRIP. 


par-  ut 


IS  t ~ot 


\ 


Transaction 


Message  h K B B B B B 

0 2 0 0 0 1 1 

0 2 1 1 8 0 0 

0 0 0 2 2 0 1 


BBBBBBBBBB 
3 3 33666666 
0011000333 
010  1014012 


bbbdddddddd 
688  1 1 11  13  33 

3774448-8000 

30123406348 


Costing 

Costing 

Correction 


XX  XXXXX  XXXXXXXXX  X X X X X 

XX  XXXXX  X XXX  XX 


X X X X 

X X X X 


X X 


to 


I' 


Figure  2.10-41g.  - Disbursement  messages  by  transaction  - costing. 


I 


Transaction 


Message  ABBBBBBBBBB 
0 1111111111 
0 0 0 1 1 1 2 2 2 3 3 

0 010  1 501609 

Prior  year  reopening 

Feopenlng  X X X X X X X X XX 

Correction  XXX  X X x X 


Message  B B B B B E E 3 B B 3 

4 7 7 7 7 7 7 7 7 7 7 

0 1 1 1 4 4 4 7 7 7 7 

Transaction  01231230123 

Prior  year  reopening 

reopening  XX  XX  X X X X 

Correction  XXX  XX  XX 


BBBBEEB  BBBBBBB  B3EBEB 

1 11  11223333  3 33333333 

777990  0 0 0122  3 3444678 

0 14  0 10  10  110  10  10  12  10  0 


X X X X X X X X X x X X X X X X X X X X 

XX  X X X X X X X X X X X X X X 


B BCCCCCC  ODD  D D0DDDD  B D 
8 8 5 5 5 5 5 5 1 T 1 1 1 3 3 3 3 3 3 3 
8 8 0000018889900001  16 
01067  8 900  16276789*32 


X X X X X X 7 

x x x x x x x x x x x x x x x r 


Figure  2.10-41h.  - Disbursement  messages  by  transaction  - prior  year  reopening. 


0 A 
^ y 


Message 


Transaction 

Miscellaneous  disbursement 
Disbursement 
Update 
Correction 

Current  year  reopening 
Cancelled  check 


AABBBBBBBB 
0 2 0 1 1 1 1 1 1 1 
0 2 6 0 0 1 1 1 2 2 
0 0 2 0 1 0 1 5 0 1 


X xxxxx  x x 

XXX  X X X 

X X XXX  XX  X 

X X X 


3BBBBBBBBB 
111111112  2 
2 337779900 
60901  4 0101 


XXXXXXXXX 
X XX  X X 

X XX  X X 


BBBBBBBBB 
33  3 333333 

001223344 
0 110  10  10  1 


XXXXXXXXX 
XXX  XXXXX 
XXX  XXXXX 
XXX 


Message  B B 

3 3 

4 6 

Transaction  2 0 

Miscellaneous  disbursement 
Disbursement  XX 

Update  X 

Correction  X 

Current  year  reopening 
Cancelled  check 


BBB  B BB  BBCCCCCC 

3 4 6666  9 9455  5 55 

6 0777733500000 

1 0 01  23  0 1006789 


X X X X XXX  XXX 

XXXXX  X X XX 

X X X X X XX 

X 
X 


CDDDDDDDDDDDD 
5111111333335 
1444888000063 
02340166  7 8910 


X X 

XXXXX  XXXXX  X 

XXXXX  XXXXX  X 

X X 


Figure  2.10-411.  - Disbursement  messages  by  transaction  - miscellaneous 


Message 


A&B'BBBBBBBBBBBBB.  BBB.BBBB  b b 
02  01  111  111111111112233333 

026  0 0 1 11  2 2 2337779900  1 1 2 2 3 

Transaction  00  20  1 01  501609014010101010 


MILSTRIP/FE8STRIP  obligation 

Obligation 

Update 

Correction 


X xx  xxxxx 

x x x x x xx  x 

xxxxx  XX  X 


X X X X X X X 

X XX  X 

X XX  X 


X X X X X X X 

X X XX 

X X XX 


Transaction 


Message  B BBBBBBBBBB  BBCC  CDDDDDDDD 
3333666  6 666885551  1 1 11133 

344400055557700044  4 88800 

10  120  140123  0 1067  2 3401  667 


MI LSTRI P/FEDSTRIP  obligation 

Obligation 

Update 

Correction 


X X X X X X X X 

X X X X 

X X X X 


X X X X X X X 

XX  XX 

XX  XX 


X X 

X X X X XXX 

X X X X XXX 


Figure  2. 10-41 j.  - Disbursement  messages  by  transaction  ~ MILSTRIP/FEDSTRIP  obligation. 


10-155 


Inquiry  description 


Input  data  elements 


Timing 


Response  data  elements 


t'4 

V 


Contract/Order  status 


Purchase  Reguest  status 


to 


Item 


Item 


Contract/Order  Humber  Immediate 


Purchase  Request  Number  Immediate 
Suffix  (where  other 
than  base  Suffix 
status  required) 


Contract/Order  Number 

Last  contract  schedule  number 

Last  contract  amendment  number 

Contractor  name  code 

Contract  Obligation 

Contract  Cost 

Contract  Disbursement 

Contract  deposit  on  containers 

Contract  payment  by  others 

Contract  payment  on  reimbursable  orders 

Contract  discount 

Contract  withholding 

Contract  cancelled  check 

Contract  advance  established 

Contract  advance  liquidated 

Letter  of  credit  number 

Contract  issuance 

Contract  withdrawal 

Purchase  Request  Number 
Suffix 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Object  Class 
Performing  Organization 
Primary  Job  Code 
Secondary  Job  Code 
Contract/Order  Number 
Contract  Schedule  Number 
Amendment  Number 
Contractor  name  code 
Commitment 
Obligation 
Cost  * 

Disbursement 
Deposit  on  containers 
Payment  by  others 
Discount 
Withholding 
Cancelled  check 
Advance  established 
Advance  liquidated 
Issuance 


Figure  2.10-42.  - Disbursement  inquiry  requirements. 


Inquiry  description 


line 


Input  dataelements 


Response  data  elements 


Government  Bill  of 
status 


MILSTRIP/FEDSTRIP 
item  status 


Letter  of  credit 
control  status 


Letter  of  credit 
issuance  status 


Letter  of  credit 
withdrawal  status 


Timing 


Lading  Item  Government  Bill  of  Immediate 

Lading  Number 
Suffix  (when  other  than 
base  Suffix  status 
reguired) 


Item  MILSTRIP/FEDSTRIP  Immediate 

Number 

Suffix  (when  other  than 
base  Suffix  status 
reguired) 


Item  Letter  of  credit  number  Immediate 


Item  Letter  of  credit  number  Immediate 

Program  Year 


Item  Letter  of  credit  number  Immediate 

Program  Year 


GBL  Humber 
Suffix 

Hethod  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 

Responsible  Organization 

Object  Class 

Performing  Organization 

Primary  Job  Code 

Secondary  Job  Code 

Commitment 

Obligation 

Cost 

Disbursement 
Discount 
Cancelled  check 

MILSTRIP/FEDSTRIP  Number 
Suffix 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 

Responsible  Organization 

Object  Class 

Performing  Organization 

Primary  Job  Code 

Secondary  Job  Code 

Commitment 

Obligation 

Cost 

Disbursement 
Cancelled  check 
Advance  established 
Advance  liguidated 

Letter  of  credit  number 

Letter  of  credit  issuance 

Letter  of  credit  withdrawal 

Last  letter  of  credit  voucher  number 

Last  serial  number 

Letter  of  credit  disbursement 

Last  voucher  number 

Letter  of  credit  number 
Program  Year 

Letter  of  credit  issuance 
Last  voucher  number 

Letter  of  credit  number 
Program  Year 

Letter  of  credit  withdrawal 
Last  voucher  number 


Figure  2,10-42.  - Disbursement  inquiry  requirements  (continued). 


10-157 


Type 


input  data  elements 

Contract/Order  Purchase  List  Contract/Order  Number 

Beguest  list 


Contract  Purchase  Heguest 
list  for  contract  schedule 


Contract/Order  Number 
Contract  Schedule 
Number 


Letter  of  credit  contract  List  Letter  of  credit  number 

list 


Contract  Purchase  Bequest  Summary 

summary  for  contract 

schedule 


Contract/Order  Number 
Contract  Schedule 
Number 


Performance  grand  total  Summary  Hone  reguired 

(open  records  only) 


Figure  2.10-112.  - Disbursement  i 


A \ 


Same  day  All  PR's  for  the  contract  or  order 

with  accounting  information  and  the 
commitment,  obligation,  cost,  and 
disbursement  for  each- 

Same  day  ill  EE-s  for  the  contract  schedule 

with  accounting  information  and  the 
commitment,  obligation,  cost,  and 
disbursement  for  each- 

Same  day  ill  contracts  fox  the  letter  of  credit 

with  the  commitment,  obligation,  cost, 
and  disbursement  for  each. 

Same  day  Contract/Order  Number 

Contract  schedule  number 

Schedule  Commitment 

Schedule  Obligation 

Schedule  Cost 

Schedule  Disbursement 

Schedule  deposit  on  containers 

Schedule  payment  by  others 

schedule  payment  on  reimbursable  orders 

schedule  discount 

Schedule  withholding 

Schedule  cancelled  check 

Schedule  advance  established 

Schedule  advance  liguidated 

Schedule  issuance 

Schedule  withdrawal 

Overnight  ‘Total  Commitment 

Total  Obligation 
Total  cost 
Total  Disbursement 
Total  disbursement  (grants) 

Total  disbursement  (letter  of  credit) 

Total  deposit  on  containers 

Total  payment  by  others 

Total  payment  on  reimbursable  orders 

Total  discount 

Total  withholding 

Total  cancelled  check 

Total  advance  established  (contracts) 

Total  advance  liguidated  (contracts) 

Total  advance  established  (grants) 

Total  advance  liguidated  (grants) 

Total  advance  established  (T-orders) 

Total  advance  liguidated  (T-orders) 

Total  advance  established  (HILSTRIP/FEOSTRIP) 
Total  advance  liguidated  (HILSTRIP/FEDSTRIP) 
Total  letter  of  credit  issuance 
Total  letter  of  credit  withdrawal 


uiry  requirements  (concluded) . 


Part  V - BPA 

Part  VI  - Government  Bill  of  Lading 
Part  VII  - MIL STRIP /FED STRIP 
Part  VIII  - Government  Orders 

• Open  Commercial  Order  Status  (White  Sands) 

• Closed  Commercial  Order  Status 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  Disbursement  Section  report  described 
in  section  2.19. 


2.11  SUBAUTHORIZATION  PERFORHANCE  PROCESS 


Subauthorization  performance  data  represents 
commitment,  obligation,  cost,  and  disbursement  (COCD)  for 
vork  being  performed  by  other  NASA  centers  in  support  of 
JSC.  Subauthorizations  issued  to  other  centers  are 
discussed  in  the  PWA  process  (section  2.4) . 

2.11.1  Update  Requirements 

2.11.1.1  Initial  input.  Subauthorization  performance 
data  activity  reported  to  JSC  by  other  NASA  centers  having 
JSC  subauthorizations  is  recorded  to  track  the  status  of 
subauthorizations  and  to  update,  when  necessary,  the  balance 
of  funds  in  the  proper  Sub-RA  PWA  account  entry.  These 
reports  are  received  at  JSC  in  the  Fund  Control  Unit. 

Information  is  reported  to  JSC  by  the  PWC  in  the 
Headguarters  coding  structure.  The  performance  activity  is 
reported  in  one  of  the  following  dollar  formats: 

• Current  period 

• Fiscal  year-to-date 

• cumulative-f rom-inception 

The  PWC  must  be  recorded  in  the  data  base  in  the 
Headquarters  coding  structure.  All  performance  data  must 
have  current  month,  fiscal  year-to-date,  and  cumulative- 
from-inception  (CFI)  dollars  for  commitment,  obligation, 
cost,  and  disbursement. 


2.11-1 


Input  ~ The  information  that  must  be  input  for  the 
Subauthorization  performance  data  received  and  the  edits  to 
be  performed  are  described  in  figure  2.11-1.  The  template 
to  be  used  for  the  Subauthorization  performance  data  input 
is  shown  in  figure  2.11-2. 

££2£§§ii£2  - The  subauthorization  performance  data  is 

controlled  by  MA,  PYr  IS,  Subauthorization  Identifier,  and 
PWC  for  all  appropriations  (R&PM,  RSD,  and  C of  F) . All 
Subauthorization  performance  data  received  with  the  same 
identification  must  be  posted  to  the  same  account  entry. 

When  the  -Subauthorization  performance  data  is  received, 
the  COCD  fields  must  be  updated  with  the  input  dollar 
amount.  Should  the  updated  cumulative-f rom-inception  field 
result  in  a negative  amount,  processing  must  be  halted  and 
an  error  message  provided. 

Dollars  can  be  reported  three  possible  ways  within  the 
Subauthorization  performance  process:  current  period, 

fiscal  year-to-date,  and  cumulative-f rom-inception. 

• Current  period  — If  the  performance  data  is  reported 
by  current  period  dollars,  those  dollar  values  are 
used  to  overlay  the  current  month  dollar  fields. 
Also,  the  fiscal  year-to-date  and  the  cumulative- 
f rom-inception  commitment,  obligation,  cost,  and 
disbursement  fields  are  updated  by  adding  current 
month  dollar  fields  to  the  existing  fiscal  year-to- 
date  fields  and  cumulative-f rom-inception  fields. 


Mzrivnb 


r*  A 
\ ■ ' 


Tnpnt/Edit  requirements 


Error 

code 


Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  Subauthorization  performance  data 
transactions.  Must  be  numeric  and  in  the  range 
10  through  79. 

Input  for  all  Subauthorization  performance  data 
transactions.  Must  be  6M  or  be  numeric  and  in 
che  range: 

58  < PY  < current  fiscal  year 
Also  validated  with  FS  and  PWC. 

Input  for  all  Subauthorization  performance  data 
transactions.  Must  be  in  the  range  1 through  9 
or  11.  Also  validated  with  PY  and  PWC. 


Input  for  all  Subauthorization  performance  data 
transactions.  Must  be  nine  digits  and  in  Headguarters 
coding  structure.  Also  validated  with  PY  and  FS. 


B100 

B101 


B160 

B161 

B162 

B 1 20 
B121 
B122 
C500 


B130 
B 131 
C500 

B170 
B 17 1 
B174 
C500 


Input  for  all  Subauthorization  performance  data  B603 

transactions  depending  on  the  type  of  dollars  re-  B610 

ported.  Input  when  reported  by  the  other  center.  ^ B611 

When  dollars  are  reported  by  cumulative-f row-inception,  B614 
must  be  greater  than  or  egual  to  0.  When  reported  by 
current  period  or  fiscal  year-to-date,  must  be  numeric. 


Input  for  all  Subauthorization  performance  data  B603 

transactions  depending  on  the  type  of  dollars  re- 
ported.  Input  when  reported  by  the  other  center.  ^ B°21 

When  dollars  are  reported  by  cumulative-from-inception,  B624 
must  be  greater  than  or  equal  to  0.  When  reported  by 
current  period  or  fiscal  year— to— date,  must  be  numeric. 


performance  data  input  and  edit  requirements. 


Data 

element 

Element 

required 

Source 

Error 
t Z£e_ 

Input/Edit  requirements 

Error 

code 

Cost 

Dollar 

Conditional 

Performance 
data  reports 

Fatal 

Input  for  all  Subauthorization  performance  data 
transactions  depending  on  the  type  of  dollars  re- 
ported. Input  when  reported  by  the  other  center. 

When  dollars  are  reported  by  cumulative-from-inception, 
must  be  greater  than  or  equal  to  0.  When  reported  by 
current  period  or  fiscal  year-to-date,  must  be  numeric. 

B602 
B 630 
B63 1 
B634 

Disbursement 

Dollar 

Conditional 

Performance 
data  reports 

Fatal 

Input  for  all  Subauthorization  performance  data 
transactions  depending  on  the  type  of  dollars  re- 
ported. Input  when  reported  by  the  other  center. 

When  dollars  are  reported  by  cumulative-from-inception, 
must  be  greater  than  or  equal  to  0.  When  reported  by 
current  period  or  fiscal  year-to-date,  must  be  numeric. 

B603 

B641 

B644 

Dollars 

reported 

Yes 

User 

supplied 

Fatal 

Indicator  specifying  manner  in  which  dollars  are 
reported.  Uust  be  input  as  one  of  current  period, 
fiscal  year-to-date,  or  cumulative-from-inception. 

B 03  0 
B031 

For  changes 
only 

Optional 

User 

supplied 

None 

Transaction  modifier.  Input  as  either  'update*  if  the 
change  being  made  is  directed  by  documentation  or 
* correction*  if  the  change  being  laade  is  because  of 

None 

erroneous  initial  input. 


Figure  2.11-1.  - Subauthorization  performance  data  input  and  edit  requirements  (concluded). 


♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  N1  - SUBAUTHORIZATION  PERFORMANCE 
SUB  ID PY  FS  PWC 

COMMITMENT  $ , , . ± OBLIGATION  $ , , 

COST  $___, , . ± DISBURSEMENT  $ , , . ± 

DOLLARS  REPORTED  BY:  CURRENT  PERIOD  _ FY  TO  DATE 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION 


Figure  2.11-2.  - Subauthorization  performance  template 


,. ± 

CFI 


2. 1 1-5 


• Fiscal  year-to-date  - If  the  performance  data  is 
reported  by  fiscal  year-to-date  dollars,  the  current 
month  dollar  fields  must  be  calculated  by 
subtracting  previous  month  year-to-date  fields  from 
the  year-to-date  information  input  to  the 
transaction.  The  current  month  and  current  year-to- 
date  fields  can  then  be  updated.  Also,  the  current 
month  dollar  fields  can  be  added  to  the  cumulative- 
f rom-incept ion  fields  to  establish  the  current 
cumulative- from- incept ion  values . 

• Cumulative-f rom-inception  - If  the  performance  data 
is  reported  by  cumulative-from-inception  dollars, 
the  current  month  dollar  fields  must  be  calculated 
by  subtracting  previous  month  cumulative-from- 
inception  fields  from  the  cumulative-from-inception 
information  input  to  the  transaction.  The  current 
month  and  the  cumulative-from-inception  fields  can 
then  be  updated.  Also,  the  current  month  dollar 
fields  can  be  added  to  the  existing  fiscal  year-to- 
date  fields  to  establish  the  current  fiscal  year-to- 
date  values. 

If  the  input  updates  the  current  month  commitment 
dollar  fields,  the  funding  Sub-RA  PWA  account  entry  issues 
must  be  updated  with  the  current  month  commitment  dollar 
amount.  For  R6D  and  C of  F appropriations,  the  Sub-RA  PWA 
account  entry  is  identified  by  Subauthorization  Identifier, 
MA,  PY,  FS,  funding  RO , and  a five-digit  PWC.  For  RSPM 
appropriations,  it  is  identified  by  Subauthorization 
Identifier,  MA,  PY,  FS,  and  funding  RO.  The  RO  used  to 
identify  the  Sub-RA  PWA  account  entry  is  obtained  from  the 
Subauthorization  performance  data  record  being  referenced. 


2. 11-6 


A positive  current  month  commitment  amount  requires 
that  a funds  availability  check  be  made  for  that  dollar 
amount  and  that  the  Sub-RA  PWA  account  entry  issues  be 
increased  by  that  dollar  amount  provided  the  balance  of  the 
entry  does  not  become  negative.  If  the  balance  of  the  entry 
does  become  negative,  an  out-of-pbase  condition  exists  that 
must  be  recorded  in  the  data  base.  The  Sub-RA  PWA  account 
entry  issues  are  increased  by  that  dollar  amount  necessary 
to  cause  the  issues  to  be  equal  to  the  receipts  of  the 
account  entry.  The  dollar  amount  remaining  must  be  recorded 
as  an  unrecorded  commitment  in  the  Sub-RA  PWA  account.  A 
message  indicating  the  amount  of  the  unrecorded  commitment 
must  be  provided. 

A negative  current  month  commitment  amount  must  first 
reference  the  unrecorded  commitments  of  the  funding  Sub-RA 
PWA  account  entry.  If  no  unrecorded  commitment  exists,  the 
Sub-RA  PWA  account  entry  issues  are  reduced  by  the  absolute 
value  of  the  current  month  commitment  amount.  If  there  are 
unrecorded  commitments  for  the  funding  Sub-RA  PWA  account 
entry,  the  negative  current  month  commitment  amount  must  be 
used  first  to  reduce  the  unrecorded  commitments.  If  the 
entire  current  month  commitment  amount  is  not  required  to 
reduce  the  unrecorded  commitment  to  zero,  the  remaining 
portion  of  the  current  month  commitment  must  be  used  to 
reduce  the  funding  Sub-RA  PWA  account  entry  issues. 

If  the  update  to  the  Sub-RA  PWA  account  entry  issues 
results  in  a negative  field,  processing  must  be  halted,  an 
error  message  must  be  provided,  and  no  update  must  occur. 


2.11-7 


If  at  any  time  during  updating  an  out-of-phase 
condition  occurs  in  the  cumulative-f rom-inception  fields 
(disbursement  greater  than  cost,  cost  greater  than 
obligation,  obligation  greater  than  commitment,  and 
commitment  greater  than  Subauthorization  amount) , a message 
must  be  provided  displaying  all  the  cumulative-f rom- 
inception  dollar  fields. 

To  satisfy  audit  trail  reguirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Subauthorization  performance  data  transactions  will  be 
identified  in  the  transaction  history. 

Output  - Section  2.11.2  describes  the  standard  online 
responses  and  error  messages  that  are  reguired  in  the 
processing  of  this  transaction. 

2.11.1.2  Update and  correction.  The  capability  must 

be  provided  to  record  data  applicable  to  prior  reporting 
periods  but  received  in  the  current  reporting  period  and  to 
change  dollar  fields  including  current  reporting  period 
fields  once  the  initial  input  of  current  reporting  period 
data  has  been  made.  A change  specified  by  a source  document 
must  be  recorded  as  an  update  transaction  while  changes  made 
as  a result  of  erroneous  input  will  be  recorded  as  a 
correction  transaction. 

Input  - The  information  that  must  be  input  for  the 
performance  data  corrections  and  the  edits  to  be  performed 
(the  same  as  shown  for  the  initial  input)  are  shown  in 
figure  2.11—1.  The  template  to  be  used  is  shown  in  figure 
2.11-2.  Corrections  can  be  made  only  to  the  dollar  fields 


since  only  those  fields  were  established  in  the  initial 
transaction.  The  remainder  of  the  input  fields  were 
established  in  a Sub-RA  PWA  transaction  and  are  used  in  this 
transaction  as  the  key  information  required  to  locate  the 
Subauthorization  performance  data  record  to  be  corrected. 
All  dollar  amounts  input  to  an  update  or  correction 
-transaction  must  be  cumulative  values  rather  than  net  change 
values. 

Processing  - If  the  correction  dollar  input  changes  the 
commitment  dollar  field,  the  Sub-RA  PWA  account  entry  issues 
must  be  updated  with  the  input  dollar  amount  identified  to 
Subauthorization  Identifier,  MA,  PY,  FS,  funding  RO,  and  a 
five-digit  PWC  for  RSD  and  C of  F appropriations  or  funding 
Object  Class  for  RSPM  appropriations.  The  RO  used  to 
identify  the  funding  Sub-RA  PWA  account  entry  is  obtained 
from  the  Subauthorization  performance  data  record  being 
changed. 

When  Subauthorization  performance  data  is  changed,  the 
use  of  the  'As  of'  Date  will  specify  the  processing 
requirements.  Current  month  changes  require  no  'As  of' 
Date.  However,  changes  required  for  any  previous  month  data 
will  use  an  'As  of'  Date  within  the  month  of  the  data  being 
changed. 

Current  Month  Change 

The  processing  requirements  for  current  month  changes 
to  Subauthorization  performance  data  depends  on  the 
reporting  method  used  for  the  data  being  corrected. 


2.11-9 


Current  period  - If  the  Subauthorization  performance 
data  is  changed  using  current  period  dollars,  the 
dollars  input  to  the  change  transaction  are  used  to 
overlay  the  current  month  dollar  fields.  Also,  the 
fiscal  year-to-date  and  the  cumulative-from- 
inception  commitment,  obligation,  cost,  and 
disbursement  fields  are  updated  by  subtracting  the 
previous  current  month  dollar  fields  from  the 
changed  current  period  data  input  to  the 
transactions  and  adding  those  computed  amounts  to 
the  existing  fiscal  year-to-date  and  cumulative- 
f rom-inception  fields. 

Fiscal  year-to-date  - If  the  Subauthorization 
performance  data  is  changed  using  fiscal  year-to- 
date  dollars,  the  change  amounts  applied  to  the 
current  month  and  cumulative— from-inception  fields 
must  be  calculated  by  subtracting  the  previous 
fiscal  year-to-date  fields  from  the  changed  fiscal 
year-to-date  fields.  The  differences  are  added  to 
the  corresponding  current  month  and  cumulative-f rom- 
inception  fields.  The  fiscal  year-to-date  fields 
are  overlaid. 

Cumulative-f rom-inception  - If  the  Subauthorization 
performance  data  is  changed  using  cumulative-f rom- 
inception  dollars,  the  change  amounts  applied  to  the 
current  month  and  fiscal  year— to— date  fields  must  be 
calculated  by  subtracting  the  previous  cumulative- 
f rom-inception  fields  from  the  changed  cumulative- 
from-inception  fields.  The  differences  are  added  to 
the  corresponding  current  month  and  fiscal  year-to- 
date  fields.  The  cumulat ive-from-inception  fields 
are  overlaid. 


2.11-10 


P revious  Month  Changes 

Changes  to  any  data  recorded  in  a previous  month  can  be 
made  only  by  user  determination  of  the  correct  values  of  the 
cumulative-from-inception  commitment,  obligation,  cost,  and 
disbursement  fields.  These  values  are  input  as  cumulative- 
from-inception  dollars  (the  only  option  permitted  for 
previous  month  changes) . The  changes  to  the  fiscal  year-to- 
date  fields  must  be  calculated  by  subtracting  the  previous 
cumulative-f rom-inception  fields  from  the  changed 
cumulative-from-inception  fields.  The  differences  are  added 
to  the  corresponding  fiscal  year-to-date  fields  and  the 
cumulative-from-inception  fields  overlaid.  As  the  change  is 
applicable  to  previous  month  data,  no  change  is  recorded  in 
any  current  month  field. 

If  any  change  results  in  the  computation  of  a negative 
dollar  amount  in  any  cumulative-from-inception  field, 
processing  must  be  halted  and  an  error  message  displayed. 

To  satisfy  audit  trail  requirements,  the  correction 
information  must  be  recorded  in  a transaction  history. 

Output  - Section  2.11.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  this  transaction. 

2.11.2  Output  Message  Requirements 

Figures  2.11-3  through  2.11-7  contain  a list  of  output 
message  requirements.  Figure  2.11-8  contains  a correlation 
of  output  messages  by  the  Subauthorization  performance  data 


2. 11-11 


Code 


****  SOB  PERFORMANCE  TRANSACTION  - CURRENT  PERIOD 

****  SUB  PERFORMANCE  TRANSACTION  - FISCAL  YEAR-TO-DATE 

****  SUB  PERFORMANCE  TRANSACTION  - CU MULATIVE-FROM-INCEPTION 

B030  DOLLARS  REPORTED  BY  NOT  SPECIFIED 

B 03 1 MULTIPLE  DOLLARS  REPORTED  BY  SPECIFIED 

Figure  2.11-3.  - Subauthorization  performance  data 
transaction-begun  messages. 


Code  Message 

A 000  PROCESSING  COMPLETE 

Figure  2.11-4.  - Subauthorization  performance  data 
transaction-complete  messages. 


2.11-12 


Code  Message 

B 1 00  'AS  OF'  DATE  INVALID 

B101  'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE  — / — / — 
B 1 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

B122  PY  MUST  BE  58  TO  CURRENT  FISCAL  YEAR 

B 1 30  FS  NOT  ENTERED 

B 1 31  FS  MUST  BE  1 TO  9 OR  11 

B160  SUB  ID  NOT  ENTERED 

B 161  SUB  ID  INVALID 

B 162  SUB  ID  MUST  BE  10  TO  79 

B1 70  PWC  NOT  ENTERED 

B 171  PWC  INVALID 

B174  PWC  MUST  BE  9 DIGITS 

B603  NO  $ AMOUNTS  ENTERED 

B6 1 0 COMMITMENT  $ NOT  ENTERED 

B6 1 1 COMMITMENT  $ INVALID 

B614  COMMITMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 

B620  OBLIGATION  $ NOT  ENTERED 

B621  OBLIGATION  $ INVALID 

B624  OBLIGATION  $ MUST  NOT  BE  LESS  THAN  ZERO 

B630  COST  $ NOT  ENTERED 

B631  COST  $ INVALID 

B634  COST  $ MUST  NOT  BE  LESS  THAN  ZERO 
B641  DISBURSEMENT  $ INVALID 

B644  DISBURSEMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 
C500  PY,  FS,  PWC  COMBINATION  INVALID 

Figure  2.11-5.  - Subauthorization  performance  data 
element  edit  error  messages. 


2.11-13 


Code 


Message 


A200  ADVISORY  - CFI  COMMITMENT  $ GREATER  THAN  SUB AUTHORIZATION  AMOUNT  $ 

HA PY FS RO PWC SUB  ID  __ 

COMMITMENT  $ , • SOB  AMOUNT  $ , , • — 

A201  ADVISORY  - CFI  OBLIGATION  $ GREATER  THAN  COMMITMENT  $ 

py FS RO  __  PWC  SUB  ID 

OBLIGATION  $ , , • COMMITMENT  $ , , ■ — 

A202  ADVISORY  - CFI  COST  $ GREATER  THAN  OBLIGATION  $ 

HA PY FS RO PWC  SUB  ID 

COST  $ _ , , t • OBLIGATION  $ » r • — 

A203  ADVISORY  - CFI  DISBURSEMENT  $ GREATER  THAN  COST  $ 

HA PY FS RO PWC  SUB  ID 

DISBURSEMENT  $ , • COST  $ , , — 

A204  ADVISORY  _ UNRECORDED  COMMITMENT  ESTABLISHED  OR  INCREASED 

HA PY FS RO PWC  SUB  ID 

UNRECORDED  COMMITMENT  $_, • + 


, - Subauthorization  performance  data  processing 
advisory  messages. 


Figure  2.11-6 


Code 


Message 


D 1 42 


PWA  ISSUES  INSUFFICIENT 


MA  „ PY 

FS 

RO 

PWC 

OBJECT  CLASS 

CARRIER  ID 

SUB 

ID 

ISSUES  $ _ , f. 

, . 

UPDATE  $ , , 

- 

D 1 60 

SUB  PERFORMANCE 

RECORD 

NOT 

FOUND 

MA  PY 

FS 

RO 

PWC 

SUB 

ID 

D 1 62 

SUB  PERFORMANCE 

COMMITMENT 

$ INSUFFICIENT 

MA  PY 

FS 

RO 

PWC 

SUB 

ID 

COMMITBENT 

r r 

UPDATE  

/ 

* • ~ 

D 1 63 

SUB  PERFORMANCE 

OBLIGATION 

$ INSUFFICIENT 

MA PY 

FS 

RO 

PWC 

SUB 

ID 

OBLIGATION  $_ 



. _ 

UPDATE  $_, , 

_ r ___  • 

D 1 64 

SUB  PERFORMANCE 

COST  $ 

INSUFFICIENT 

MA PY 

FS 

RO 

PWC 

SUB 

ID 

COST  , 

r • 

UPDATE  , , . 



D 1 65 

SUB  PERFORMANCE 

DISBURSEMENT  $ INSUFFICIENT 

MA PY 

FS 

RO 

PWC 

SUB 

ID 

DISBURSEMENT  $_ 

, , 

, 

.. UPDATE  

, 

yf ) ^ 

Figure  2.11-7.  - Subauthorization  performance  data  processing 

error  messages. 


2.  11-15 


11-16 


Messages  A A A A A A B B B B BBBBBBB  BB  BBB 
0222  220011111111111116 
0 0 00003300222336667770 

Transaction  0012340101012010120143 


Subauthorization  performance 

Current  period  XXXXXXXXXXXX  XXXXXXXXX 
Fiscal  year-to-date  XXXXXXXXXXXX  XXXXXXXXX 
Cumulative-from-inception  XXX  XXXXXXXXX  XXXXXXXXX 


Messages  B B BBBBBB  BBBCDDDDDD 
6666  6 6666665111111 

1 112  2 2 333440466666 

Transaction  01401401  4140202345 


Subauthorization  performance 

Current  period  X X XXXXXXXXX 
Fiscal  year-to-date  XX  XX  X X X XXX  X XXX 
Cumulative-from-inception  XX  XXXXXXXXXXXXXXXX 


Figure  2.11-8.  - Subauthorization  performance  data  messages  by  transaction. 


transaction. 


2.11.3  Inquiry  Requirements 

Figure  2.11-9  contains  a list  of  inquiry  input  data 
elements  and  response  data  elements  required  for 
Subauthorization  performance  processing. 

2.11.4  Report  Requirements 

Section  2.19.11  lists  the  Subauthorization  performance 
report  requirements.  The  following  reports  reflect  Sub-RA 
PWA  account  activity  and  Subauthorization  performance  data 
activity. 

• Subauthorization  Performance  From  Inception 

• Subauthorization  Performance  by  RO 

• Status  of  Subauthorization  Recap  of  Year-to-Date 

Activity  by  Organization 

• Status  of  Subauthorization  Recap  of  Year-to-Date 

Activity-Centerwide 


i 


2. 1 1-17 


Inquiry  description 


Type 


Input  data  elements 


Timing 


Response  data  elements 


Subauthorization  perform- 
ance data 


Subauthorization  perform- 
ance data  summary  by  a 
five-digit  Primary  Work 
Code 


item  Subauthorization 

Identifier 
Program  Year 
Fund  Source 
Primary  Work  Code 
(nine  digits) 


Summary  Subauthorization 

Identifier 
Program 
Fund  Source 
Primary  Work  Code 
(five  digits) 


Immediate  Subauthorization  Identifier 

Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Subauthorization  Amount 
Current  month  Commitment 
Current  month  Obligation 
Current  month  Cost 
Current  month  Disbursement 
Fiscal  year-to-date  Commitment 
Fiscal  year-to-date  obligation 
Fiscal  year-to-date  Cost 
Fiscal  year-to-date  Disbursement 
Cumulative-from-inception  Commitment 
Cumulative-from-inception  Obligation 
Cumulative-from-inception  Cost 
Cumulative-from-inception  Disbursement 

Immediate  Subauthorization  Identifier 
Program  Year 
Fund  Source 

Primary  Work  Code  (five  digits) 

Sub-RA  PW A receipts 

Current  month  Commitment 

Current  month  Obligation 

Current  month  Cost 

Current  month  Disbursement 

Fiscal  year-to-date  Commitment 

Fiscal  year-to-date  obligation 

Fiscal  year-to-date  Cost 

Fiscal  year-to-date  Disbursement 

Cumulative-from-inception  Commitment 

Cumulative-from-inception  Obligation 

Cumulative-from-inception  Cost 

Cumuli tive-from-inception  Disbursement 

Unrecorded  Commitment 


Figure  2.11-9.  - Subauthorization  performance  data  inquiry  requirements. 


description 


Type  Input  data  elements  Tiding 


Subauthorization  perform-  Summary 
ance  data  summary  by  a 
four-digit  Primary  Work 
Code 


Subauthorization  Iden-  Immediate 
ti f ier 

Program  Year 
Fund  Source 
Primary  Work  Code 
(four  digits) 


Subauthorization  perform-  Summary 
ance  data  summary  by  a 
three-digit  Primary  Work 
Code 


Subauthorization  Immediate 

Identifier 
Program  Year 
Fund  Source 
Primary  Work  Code 
(three  digits) 


Subauthorization  perform-  Summary 

ance  data  summary  by  Fund 

Source 


Subauthorization 
Identifier 
Program  Year 
Fund  Source 


Immediate 


Response  data  elements 


Subauthorization  Identifier 
Program  Year 
Fund  Source 

Primary  Work  Code  (four  digits) 

Sub-R A PW A receipts 

Current  month  Commitment 

Current  month  Obligation 

Current  month  Cost 

Current  month  Disbursement 

Fiscal  year-to-date  Commitment 

Fiscal  year-to-date  Obligation 

Fiscal  year-to-date  Cost 

Fiscal  year-to-date  Disbursement 

Cumulative-f rom-inception  Commitment 

Cumulative- f rom-inception  Obligation 

Cumulative-from-inception  Cost 

Cumulative-f rom-inception  Disbursement 

Unrecorded  Commitment 

Subauthorization  Identifier 
Program  Year 
Fund  Source 

Primary  Work  Code  (three  digits) 

Sub-HA  PWA  receipts 

Current  month  Commitment 

Current  month  obligation 

Current  month  Cost 

Current  month  Disbursement 

Fiscal  year-to-date  Commitment 

Fiscal  year-to-date  Obligation 

Fiscal  year-to-date  Cost 

Fiscal  year-to-date  Disbursement 

Cumulative-from-inception  Commitment 

Cumulative-from-inception  Obligation 

Cumulative-from-inception  Cost 

Cumulative-from-inception  Disbursement 

Unrecorded  Commitment 

Subauthorization  Identifier 

Program  Year 

Fund  Source 

Sub-HA  PWA  receipts 

Current  month  Commitment 

Current  month  Obligation 

Current  month  Cost 

Current  month  Disbursement 

Fiscal  year-to-date  Commitment 

Fiscal  year-to-date  Obligation 

Fiscal  year-to-date  Cost 

Fiscal  year-to-date  Disbursement 

Cumulative-from-inception  Commitment 

Cumulative-from-inception  Obligation 

Cumulative-from-inception  Cost 

Cumulative-from-inception  Disbursement 

Unrecorded  Commitment 


Figure  2.11-9.  - Subauthorization  performance  data  inguiry  requirements  (continued) 


11-20 


Inquiry  description 


Type 


Input  data  elements 


Timing 


Subauthorization  perform- 
ance data  summary 


Subauthorization  perform- 
ance data  summary  by  a 
five-aigit  Primary  Work 
Code  within  Responsible 
Organization 


Subauthorization  perform- 
ance data  summary  by  a 
four-digit  Primary  Work 
Code  within  Responsible 
Organization 


Response  data  elements 


Summary  Subauthorization  Immediate 

Identifier 


Summary  Responsible  Organiza-  Immediate 

tion 

Program  Year 
Primary  Work  Code 
(five  digits) 

Subauthorization 

Identifier 


Summary 


Responsible  Organiza-  Immediate 
tion 

Program  Year 
Fund  Source 
Primary  Work  Code 
(four  digits) 

Subauthorization  Iden- 
tifier 


Subauthorization  Identifier 

Sub-R A PWA  receipts 

Current  month  Commitment 

Current  month  Obligation 

Current  month  Cost 

Current  month  Disbursement 

Fiscal  year-to-date  Commitment 

Fiscal  year-to-date  Obligation 

Fiscal  year-to-date  cost 

Fiscal  year-to-date  Disbursements 

Cumulative-from-inception  Commitment 

Cumulative-f rom-inception  Obligation 

Cumulative-from-inception  Cost 

Cumulative-from-inception  Disbursement 

Unrecorded  Commitment 

Responsible  Organization 
Program  Year 
Fund  Source 

Primary  Work  Code  (five  digits) 
Subauthorization  Identifier 
Sub-RA  PWA  receipts 
Current  month  Commitment 
Current  month  Obligation 
Current  month  Cost 
Current  month  Disbursement 
Fiscal  year-to-date  Commitment 
Fiscal  year-to-date  obligation 
Fiscal  year-to-date  Cost 
Fiscal  year— to— date  Disbursement 
Cumulative-from-inception  Commitment 
Cumulative-from-inception  Obligation 
Cumulative-from-inception  Cost 
Cumulative-from-inception  Disbursement 
Unrecorded  Commitment 

Responsible  Organization 
Program  Year 
Fund  Source 

Primary  Work  Code  (four  digits) 
Subauthorization  Identifier 
Sub-RA  PW A receipts 
Current  month  Commitment 
Current  month  Obligation 
Current  month  Cost 
Current  month  Disbursement 
Fiscal  year-to-date  Commitment 
Fiscal  year-to-date  Obligation 
Fiscal  year-to-date  Cost 
Fiscal  year-to-date  Disbursement 
Cumulative-from-inception  Commitment 
Cumulative-from-inception  obligation 
Cumulative-from-inception  Cost 
Cumulative-from-inception  Disbursement 
Unrecorded  Commitment 


Figure  2.11-9. 


- Subauthorization  performance  data  inquiry  requirements  (continued) . 


Subauthorization  perform- 
ance data  summary  by  a 
three-digit  Primary  Work 
Code  within  Responsible 
Organization 


Subauthorization  perform- 
ance data  summary  by  Fund 
Source  within  Responsible 
Organization 


Sub^ uthorization.  perform- 
ance data  out-of-phase 


Tyne 


Input  data  elements  Timing 


Response  data  elements 


Summary 


Summary 


List 


Responsible  Organiza-  Immediate 
tion 

Program  Year 
Fund  Source 
Primary  Work  Code 
(three  digits) 

Subauthorization 

Identifier 


Responsible  Organiza-  Immediate 
tion 

Program  Year 
Pund  Source 
Subauthorization 
Identifier 


Subauthorization  Iden-  Immediate 
tifier 

Program  Year 
Primary  Work  Code 
(five  digits) 

Responsible  Organiza- 
tion 


Responsible  Organization 
Program  year 
Fund  Source 

Primary  Work  Code  (three _ digits) 
Subauthorization  Identifier 
Sub-RA  PWA  receipts 
Current  month  Commitment 
Current  month  Obligation 
Current  month  Cost 
Current  month  Disbursement 
Fiscal  year-to-date  Commitment 
Fiscal  year-to-date  Obligation 
Fiscal  year-to-date  Cost 
Fiscal  year-to-date  Disbursement 
Cumulative-from-inception  Commitment 
Cumulative-from-inception  Obligation 
Cumulative-from-inception  Cost 
Cumulative-f rom-inception  Disbursement 
Unrecorded  Commitment 

Responsible  Organization 
Program  Year 
Fund  Source 

Subauthorization  Identifier 

Sub-RA  PWA  receipts 

Current  month  Commitment 

Current  month  Obligation 

Current  month  Cost 

Current  month  Disbursement 

Fiscal  year-to-date  Commitment 

Fiscal  year-to-date  Obligation 

Fiscal  year-to-date  Cost 

Fiscal  year-to-date  Disbursement 

Cumulative-from-inception  Commitment 

Cumulative-from-inception  obligation 

Cumulative-from-inception  Cost 

Cumulative-from-inception  Disbursement 

Unrecorded  Commitment 

Subauthorization  Identifier 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Sub-RA  PWA  receipts 

Cumulative-from-inception  Commitment 
Cumulative-from-inception  Obligation 
Cumulative-from-inception  Cost 
Cumulative-from-inception  Disbursement 


Figure  2.11-9.  - Subauthorization  performance  data  inguiry  requirements  (concluded) 


2.12.  -TRAVEL  PROCESS 


The  Travel  process  includes  the  certification  of  funds 
availability  and  the  recording  of  commitment,  obligation, 
cost,  and  disbursement  of  all  funds  reguired  for  domestic 
and  overseas  travel  and  permanent  change  of  official  station 
(PCS)  activities  of  NASA/JSC  employees  and  others  whose 
travel  expenses  are  paid  by  JSC. 

2.12.1  Update  Requirements 

The  Travel  Unit  receives  a travel  order  or' a PCS 
document  which  establishes  the  conditions  under  which 
official  travel,  transportation,  and  moving  expenses  are 
authorized  by  federal  regulations.  The  travel  order 
includes  information  concerning  the  traveler  (name  and  name 
code) , pertinent  dates  or  assignment  period,  mode  of 
transportation,  allowances,  and  fund  and  accounting 
information.  The  types  of  travel  authorized  by  these 
documents  are  as  follows: 

• Temporary  duty  travel  (domestic)  - travel  within  the 
50  States,  the  District  of  Columbia,  Puerto  Rico, 
the  Canal  Zone,  and  possessions  of  the  United 
States.  The  Travel  Unit  uses  the  Travel  Request  and 
Authorization,  NASA  Form  372,  to  establish  per  diem, 
rental  car,  transportation,  and  excess  baggage 
expense  information. 

• Temporary  duty  travel  (foreign)  - travel  outside  the 
areas  described  in  temporary  duty  travel  (domestic)  . 
The  Travel  Unit  uses  the  Overseas  Travel  Order,  NASA 
Form  386,  to  establish  per  diem,  rental  car. 


transportation,  and  excess  baggage  expense 
information. 

• Continuing  and  repetitive  travel  - travel  for 
employees  requiring  repetitive  travel.  Continuing 
and  repetitive  travel  is  authorized  via  a Travel 
Request  and  Authorization,  NASA  Form  372,  and  a 
Miscellaneous  Obligations  Document  - General  Travel 
Authorization,  NASA  Form  576,  and  is  issued  to 
establish  per  diem,  rental  car,  transportation,  and 
excess  baggage  expenses  for  each  individual  trip. 

PCS  expenses  are  authorized  via  an  Authorization  Change 
of  Official  Station,  NASA  Form  1450.  The  types  of  activity 
authorized  which  must  be  controlled  and  recorded  are  the 
following: 

• Per  diem 

• Transportation 

• Movement  of  household  goods 

• Househunting  expenses 

• Temporary  quarters  expenses 

• Sale  of  real  estate  expenses 

• Purchase  of  real  estate  expenses 

• Miscellaneous  expenses 

The  Travel  process  requires  the  certification  of  funds 
availability  and  the  recording  of  performance  data  through 
cost  upon  initiation  of  any  travel  or  PCS  activity.  In 
addition,  any  advance  of  funds  given  must  be  recorded  as  an 
establishment  of  an  advance.  When  the  travel  or  PCS 
activity  has  been  completed,  the  recording  of  disbursements 
will  reflect  the  expenses  incurred.  Any  advance  of  funds 


2.12-2 


must  also  be  liquidated.  The  following  sections  discuss  the 
input,  processing,  and  output  requirements  for  these  various 
transactions. 


2.12.1.1  Travel performance through cost.  Data 

provided  on  all  travel  documents  received  in  the  Travel  Unit 
must  be  recorded  and  available  for  later  reference.  All 
travel  documents  must  undergo  a certification  of  funds 
availability  process  and/or  the  recording  of  data  required 
in  the  fund  accounting  process  (performance  data) . 

Input  - Information  that  must  be  input  for  all  travel 
documents  requiring  the  recording  of  performance  data 
through  cost  is  obtained  from  the  travel  order,  PCS 
document,  or  user  supplied  information  derived  from  the 
travel  documents.  Input  data  elements  and  data  edits 
required  are  shown  in  figure  2.12-1.  The  type  of  travel 
activity  codes,  specified  data  element  relationships,  and 
additional  edit  requirements  are  shown  in  figure  2.12-2. 
Figure  2.12-3  defines  the  template  required  for  input  of 
these  data  elements. 

Travel  orders  and  PCS  documents  will  require  the  input 
of  a transaction  for  each  applicable  travel  activity 
(defined  in  figure  2.12-2),  and  the  complete  set  of 
accounting  information  must  be  available  for  each 
transaction.  However,  the  user  input  of  the  complete  set  of 
information  usually  will  be  necessary  for  only  one  of  the 
activities  having  the  same  Travel  Authorization  (TA)  Number 
and  Trip  Number  (if  applicable) . 


Data 

Element 

Error 

Error 

element 

required 

Source 

tvpe 

Input/Edit  requirements 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B 10 1 

Travel 

Authorization 

Number 

Yes 

Travel 

document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. The  first  character  must  be  alphabetic, 
and  the  remaining  five  must  be  numeric. 

cooo 

C001 

Trip  Number 

Conditional 

General 

Travel 

Authorization 

Fatal 

Identifies  a specific  Trip  Number  within  a General 
Travel  Authorization.  Input  for  every  General 
Travel  Authorization.  Must  be  numeric. 

C010 

C011 

Transportation 

Reguest 

Number 

Conditional 

Transportation 

Request 

Fatal 

Conditional  input  based  on  the  type  of  travel  activi- 
ty. Must  input  if  it  is  a transportation  activity. 
The  first  character  must  be  alphabetic.  The  remain- 
ing seven  must  be  numeric.  See  figure  2.12-2  for 
additional  edits. 

C020 

C021 

C022 

Type  of 

travel 

activity 

•Yes 

User  supplied 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. The  first  three  digits  must  be  numeric,  and 
the  fourth  must  be  alphabetic.  See  figure  2.12-2  for 
additional  edits. 

C030 
C03 1 

fund  Source 

Yes 

User  supplied 
or  travel 
order 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  the  value  1,  2,  or  3.  See  figure 
2.12-2  for  additional  edits. 

B130 

B136 

B139 

C500 

C506 

C507 

Object  Class 

Yes 

Travel 

document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  a valid  Object  Class.  See  figure 
2.12-2  for  additional  edits. 

B 190 
B 1 91 

Commitment, 
Obligation, 
and  Cost 
Dollar  Amount 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  numeric  and  not  egual  to  0. 

B660 

B661 

B662 

C410 

Disbursement 
Dollar  Amount 

Ho 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data 
initial  transaction. 

B645 

Voucher 

number 

Ho 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data 
initial  transaction. 

B932 

Final 

payment 

No 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data 
initial  transaction. 

B080 

payment  by 
others  dollars 

No 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data 
initial  transactions. 

B 08 1 

figure  2.12-1.  - Travel  performance  data  initial  input  and  edit  requirements. 


Data 

element 


Element 

required 


Source 


Iggut/Edit  requirements 


Error 

code 


Error 


Reopening 

No 

None 

None 

Must  not  be  input  for  any  Travel  performance  data 
initial  transactions. 

None 

Method  of 
Authority 

Yes 

User  supplied 
or  travel 
document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  a valid  MA  but  not  97. 

B110 

Bill 

Program  Year 

Yes 

User  supplied 
or  travel 
document 

Fatal 

Input  for  all  Travel  performance  data  initial  input 
transactions.  Must  be  a valid  PY . Also  validated 
with  FS. 

B 1 20 
B171 
B174 

Primary  Work 
Code 

Yes 

Travel 

document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  nine  digits. 

B170 
B 1 7 1 
B 1 7 4 

Responsible 

Organization 

Yes 

Travel 

document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  a valid  RO. 

B200 
B20 1 
C506 
C507 

Performing 

Organization 

Yes 

Travel 

document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  alphabetic  and  a valid  Performing 
Organization . 

B320 

B321 

Primary  Job 
Code 

Conditional 

Travel 

document 

Fatal 

Input  if  provided  on  the  source  document.  Must  be 
numeric.  If  the  first  digit  is  0 or  1,  must  be  a 
valid  Centerwide  Job  Code.  Also  validated  with  FS 
and  Performing  Organization. 

B330 
B33 1 
C506 

Secondary 
Jcb  Code 

Conditional 

Travel 

document 

Fatal 

Input  if  provided  on  the  source  document  and  a 
Primary  Jcb  Code  is  input.  Must  be  numeric.  If 
the  first  digit  is  0 or  1,  must  be  a valid  Centerwide 
Job  Code.  Also  validated  with  FS  and  Performing 
Organization. 

B340 

B341 

B342 

C507 

Name  code 

Yes 

Travel 

document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  a valid  name  code- 

C040 

com 

Tra^*'1  date 
(beginning) 

Yes 

Travel 

document 

Fatal 

input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  numeric  and  conform  to  all  normal 
date  edits. 

COSO 

C051 

Travel  date 
(ending) 

Yes 

Travel 

document 

Fatal 

Input  for  all  Travel  performance  data  initial  trans- 
actions. Must  be  numeric  and  conform  to  all  normal 
date  edits. 

C060 

C061 

C062 

- Travel  performance  aata  initial  input  and  edit  requirements  (continued). 


Figure  2.12-1. 


Data 

Element 

Error 

element 

required 

Source 

Government 
Bill  of 
Lading 
number 

Conditional 

Government 
Bill  of 
Lading 

Fatal 

Tor  changes 
only 

No 

None 

Fatal 

Ingut/Edit  regui reaents 

Conditional  input  based  on  the  type  of  travel  activi- 
ty- Input  for  shipment  of  household  goods  activity 
if  the  shipment  is  by  GBL. 

Must  not  be  input  for  any  Travel  performance  data 
initial  transaction. 


Error 

code 

B421 

None 


Figure  2.12-1.  - Travel  performance  data  initial  input  and  edit  requirements  (concluded). 


Type  of  travel 
(domestic  qnd_overseas) 

Per  die® 

Transportation 

Excess  baggage 

Rental  car 


local. aijeage 

peya^nent  change, Qg_station 

Eaployee  per  die® 

Dependent  per  die® 

Househunting 

Transportation 


Te«porary  quarters 
Real  estate  sale 
Real  estate  purchase 
Miscellaneous 

Shipment  of  household  goods 


NOTE:  n equals  any  numeral 


Type  of 
travel 
activity 
codes 

Transportation 

Request 

Humber 

Fund 

Source 

Object  Class 
/If  Fund  Sourcex 
Vi  2 3/ 

Trip 

Number 

10nA 

No 

2 

or 

3 

Any 

2181 

If 

2162 

applicable 

llnB 

Yes 

2 

or 

3 

Any 

2181 

If 

2182 

applicable 

12nB 

Yes 

2 

or 

3 

Any 

2181 

If 

2182 

applicable 

13nC 

No 

2 

or 

3 

Any 

2181 

If 

2182 

applicable 

20nA 

No 

3 

2161 

No 

30nA 

No 

2 

2051 

Ho 

2061 

31nA 

No 

2 

8081 

Ho 

32nA 

No 

2 

8082 

Ho 

33nB 

Yes 

2 

2051 

No 

2061 

8082 

34nA 

No 

1 

1711 

No 

35nA 

No 

1 

1811 

Ho 

36n  A 

No 

1 

1811 

No 

37n  A 

No 

1 

1911 

No 

38nA 

No 

1 

2241 

No 

from  0 to  9 (used  to  split  years,  e.g.,  performance  data  for  PY  1974  equals  4) 


Figure  2.12-2.  - Type  of  travel  activity  codes,  input  relationships,  and  edit  requirements 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦★TEMPLATE  NO.  Pi  - TRAVEL  PERFORMANCE 

TRAVEL  AUTH  NO.  TRIP  NO.  TRANS  REQUEST  NO 

TYPE  OF  TRAVEL  ACTIVITY  FS  OBJECT  CLASS  

C/O/C  $ , r . ± 

DISB  $ , , . ± VOUCHER  NO.  

FINAL  PAYMENT  _ PAYMENT  BY  OTHERS  _ REOPENING  _ 

MA PY PWC  RESP  ORG PERF  ORG 

PRIMARY  JOB  CODE SECONDARY  JOB  CODE  NAME 

TRAVEL  DATES;  START / / END  / GBL  NO. 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


Figure  2.12-3.  - Travel  Performance  Data  template 


Almost  all  domestic,  overseas,  and  continuing  travel 
and  PCS  moves  require  the  input  of  per  diem  activity.  The 
input  of  other  associated  activities  varies;  therefore,  the 
input  and  recording  of  all  accounting  information  in  the 
data  base  for  per  diem  activity  will  permit  the  user  to 
input  only  (1)  TA  Number  and  Trip  Number  (if  applicable) , 
(2)  type  of  travel  activity  code,  (3)  Transportation  Request 
Number  (if  it  is  a transportation  activity) , and  (4)  other 
required  data  elements  associated  only  with  the  activity 
being  input. 

For  domestic,  overseas,  and  continuing  travel,  the 
input  of  the  associated  rental  car,  transportation,  and 
excess  baggage  activities  requires  the  following  data 
elements: 

• Travel  Authorization  Number 

• Trip  Number  (for  continuing  travel) 

• Transportation  Number  (transportation  activity  only) 

• Type  of  travel  activity 

• Fund  Source 

• Object  Class 

• Dollar  Amount 

For  a PCS,  the  input  of  househunting,  transportation, 
temporary  quarters,  real  estate  sale,  real  estate  purchase, 
shipment  of  household  goods,  and  miscellaneous  expense 
activities  reguires  the  following  data  elements: 

• Travel  Authorization  Number 

• Transportation  Number  (transportation  activity  only) 

• Type  of  travel  activity 


• Object  Class 

• Fund  Source 

• Dollar  Amount 

• GBL  number  (shipment  of  household  goods  activity 
when  it  is  by  GBL) 

Local  mileage  activity  has  no  per  diem  associated  with 
the  activity.  Therefore,  all  accounting  information  must  be 
entered  by  the  user.  In  addition,  when  an  exception  occurs 
in  travel  and  PCS  activity  and  no  associated  per  diem 
activity  exists  (e.g.,  rental  car  provided  for  local  area 
travel  with  no  per  diem  paid) , all  accounting  information 
becomes  required  input. 

Processing  « The  first  processing  requirement  .for  the 
initial  input  of  travel  orders  or  PCS  activity  requiring  the 
recording  of  performance  data  specifies  that  no  performance 
data  can  already  exist  for  the  input  TA  Number,  Trip  Number 
(if  applicable) , type  of  travel  activity  code,  and 

Transportation  Beguest  Number  (if  it  is  a transportation 
activity) . If  performance  data  does  exist,  processing  must 
be  halted  and  an  error  message  provided. 

The  second  requirement  specifies  that  availability  of 
funds  in  the  funding  PWA  account  entry  be  established  for 
the  dollar  amount  input  for  each  travel  activity.  The 
funding  PWA  account  entry  is  defined  using  MA,  PY,  FS,  BO, 
and  funding  Object  Class.  The  funding  Object  Class  is 
converted  as  required  from  the  input  Object  Class  if  the  PY 
is  the  current  program  year.  Object  Class  is  not  required 
if  the  PY  is  any  year  prior  to  the  current  program  year. 
The  dollar  amount  must  be  posted  to  the  funding  PWA  account 


entry  issues  if  the  account  balance  is  sufficient  to  fund 
the  activity  being  processed;  otherwise,  processing  ceases 
and  a message  must  advise  a user  of  insufficient  funds. 


The  third  processing  requirement  specifies  the 
establishment  of  a performance  data  record  for  the  type  of 
travel  activity  being  processed  for  a travel  order  (per 
diem,  transportation,  rental  car,  or  excess  baggage)  or  a 
PCS  [per  diem  (employee  and  dependents),  househunting, 
temporary  guarters,  sale  of  real  estate,  purchase  of  real 
estate,  movement  of  household  goods,  and  miscellaneous 
expense]. 


The  following  data  elements  must  be  included: 


© 


Travel  Authorization  Number 
Trip  Number  (if  applicable) 

Type  of  travel  activity  code 

Transportation  Request  Number  (if  it  is  a transpor- 
tation activity) 

Fund  Source 
Object  Class 

Commitment,  Obligation,  and  Cost  dollars 

Method  of  Authority 

Program  Year 

Primary  Work  Code 

Responsible  Organization 

Performing  Organization 

Primary  Job  Code  (if  provided) 

Secondary  Job  Code  (if  provided) 

Name  code 
Start  date 


• End  date 

• Government  Bill  of  Lading  number  (if  applicable) 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Travel  performance  data  initial 
transaction. 


2.12.1.2  Travel disbursement.  Expenses  related,  to  a 

travel  or  a PCS  move  are  reported  on  the  Travel  Voucher, 
Standard  Form  1012.  Expenses  reimbursed  directly  to  the 
traveler  or  employee  making  a PCS  move  are  extracted  from 
this  document  and  recorded  as  disbursement  transactions  for 
the  specified  travel  activity. 

In  addition,  invoice  billings  are  received  for 
transportation,  excess  baggage,  rental  car,  government-owned 
motor  pool  cars,  and  shipment  of  household  goods  from 
commercial  carriers  and  the  Government  Services  Agency 
(GSA) . These  billings  are  verified  using  data  reported  on 
the  Travel  Voucher  and  are  also  input  as  disbursement 
transactions  for  the  specified  travel  activity.  Data 
provided  on  each  Travel  Voucher  and  invoice  billing  received 
in  the  Travel  Unit  must  be  recorded  and  available  for  later 
reference . 

- Information  that  will  be  input  for  the  Travel 
performance  data  disbursement  transaction  is  obtained  from 
the  Travel  Voucher,  invoice  billings,  or  user  supplied 


2.12-12 


invoice 


information  derived  from  the  Travel  Voucher  or 
document.  The  input  data  elements  and  data  edits  required 
are  shown  in  figure  2.12-4.  The  type  of  travel  activity 
codes,  input  data  element  relationships,  and  additional  edit 
requirements  are  shown  in  figure  2.12-2.  Figure  2.12-3 
defines  the  template  required  for  input  of  these  data 
elements. 


Processing  - The  first  processing  requirement  for  the 
disbursement  transaction  specifies  that  the  performance  data 
record  already  exist  for  the  input  TA  Number,  Trip  Number 
(if  applicable) , type  of  travel  activity  code,  and 
Transportation  Request  Number  (if  it  is  a transportation 
activity)  and  that  the  record  must  be  open.  If  a 
performance  data  record  does  not  exist  or  if  the  record  is 
closed,  processing  must  be  halted  and  an  error  message 
provided.  If  a complete  payment  is  specified  and 
disbursement  dollars  are  greater  than  commitment, 
obligation,  and  cost  dollars  in  the  performance  data  record, 
a funds  availability  check  must  be  performed.  The  funding 
PWA  account  entry  is  selected  using  MA,  PY,  FS,  HO,  and 
Object  Class. 


The  funding  Object  Class  is  converted  as  required  from 
the  input  Object  Class  if  the  PY  is  the  current  program 
year.  Object  Class  is  not  required  if  the  PY  is  any  year 
prior  to  the  current  program  year.  The  dollar  amount  must 
be  posted  to  the  PWA  account  entry  issues  if  the  account 
balance  is  sufficient  to  fund  the  additional  amount; 
otherwise,  processing  ceases  and  a message  must  advise  a 
user  of  insufficient  funds. 
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Data 

element 

Element 

required 

Source 

Error 
H E£_ 

Input/Edit  requirements 

Error 

code 

•As  of* 
Date 

optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B100 

B101 

Travel 

Authorization 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  performance  data  disbursement 
transactions.  The  first  character  must  be  alphabetic, 
and  the  remaining  five  must  be  numeric. 

COOO 

C001 

Trip  Number 

Conditional 

User  supplied 

Fatal 

Identifies  a specific  Trip  Number  within  a General 
Travel  Authorization.  Input  for  every  General  Travel 
Authorization.  Must  be  numeric. 

C01 0 

con 

Transportation 

Bequest 

Number 

No 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data 
disbursement  transaction. 

C022 

Type  of  travel 
activity 

Yes 

User  supplied 

Fatal 

Input  fci  all  Travel  performance  data  disbursement 
transactions.  The  first  three  digits  oust  be  numeric, 
and  the  fourth  must  be  alphabetic.  See  figure  2.12-2 
for  additional  edits. 

C030 

C031 

Fund  Source 

Ho 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

B14 1 

Object  Class 

No 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

B192 

Commitment 
Obligation, 
and  Cost 
Dollar  Amount 

No 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

B665 

Disbursement 
Dcllar  Amount 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  performance  data  disbursement 
transactions.  Must  be  numeric. 

B640 
B64 1 
B642 

Voucher 

number 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  performance  data  disbursement 
transactions.  Must  be  numeric. 

B930 

B931 

B933 

Final  payment 

Conditional 

User  supplied 

Fatal 

Input  for  Travel  performance  data  disbursement  trans- 
actions when  it  is  a final  payment. 

B080 

Payment  by 
others 

Conditional 

User  supplied 

Fatal 

Input  for  Travel  performance  data  disbursement  trans- 
actions when  payment  is  not  made  by  JSC. 

B081 

Eeopening 

No  ! 

None 

None 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

none 

Method  of 
Authority 

HO 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

B118 

Figure  2-12-4,  - Travel  performance  data  disbursement  input  and  edit  requirements 


Data  Element  Error 

eleaent  required  Source  type  Input/Edit  requirements 


Program  Year 

No 

None 

Fatal 

Primary  Work 
Code 

NO 

None 

Fatal 

Responsible 

Organization 

No 

None 

Fatal 

Performing 

Organization 

No 

None 

Fatal 

Primary  Jo a 
Code 

NO 

None 

Fatal 

Secondary  Job 
Code  ' 

NO 

None 

Fatal 

Name  code 

NO 

None 

Fatal 

Travel  date 
(beginning) 

NO 

None 

Fatal 

Travel  date 
(ending) 

NO 

None 

Fatal 

Government  Bill 
of  Lading 
number 

No 

None 

Fatal 

For  changes 
only 

No 

None 

Fatal 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

tfust  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 

bust  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 


Must  not  be  input  for  any  Travel  performance  data  dis- 
bursement transaction. 


So 

***  to 

If 

PS 


If 


Error 
cpd  e 

B124 

B175 

B205 

B324 

B333 

B341 

C043 

C052 

C053 

B422 

Hone 


Figure  2.12-4.  - Travel  performance  data  disbursement  input  and  edit  requirements  (concluded) 


If  the  dollar  amount  is  less  than  the  commitment, 
obligation,  and  cost  dollars  in  the  performance  data  record, 
the  difference  between  those  dollars  and  the  disbursement 
dollars  must  be"1  computed.  That  difference  is  used  to 
decrease  the  commitment,  obligation,  and  cost  dollars 
(making  all  dollars  equal)  and  to  decrease  the  funding  PWA 
account  entry  issues  (increasing  the  balance  for  that 
entry) . The  following  data  elements  must  be  added  to  the 
performance  data  record: 

• Closed  indicator 

• Disbursement  Dollars 

• Voucher  number 

If  a final  payment  is  not  specified  and  disbursement 
dollars  are  greater  than  commitment,  obligation,  and  cost 
dollars  in  the  performance  data  record,  a funds  availability 
check  must  be  performed  to  verify  a funds  balance  for  the 
appropriate  PWA  account  entry.  If  the  funds  are  available, 
the  PWA  account  entry  issues  are  increased  by  the  additional 
dollars  required  and  the  commitment,  obligation,  and  cost 
dollars  are  increased  by  a like  amount.  In  addition,  the 
disbursement  dollars  and  the  voucher  number  are  recorded. 
If  the  disbursement  dollar  amount  is  less  than  the 
commitment,  obligation,  and  cost  dollars  in  the  performance 
data  record,  the  disbursement  dollars  and  the  voucher  number 
are  recorded  in  the  performance  data  record.  If  the 
'•payment  by  others"  indicator  is  specified,  processing  will 
be  the  same  as  described  above  with  an  additional  dollar 
field  being  updated  in  the  record  for  the  payment  by  others 
dollars. 
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To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 

Output  ~ Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  reguired  in  the 
processing  of  the  Travel  performance  data  disbursement 
transaction. 


2.12.1.3  Update and correction.  After  performance 

data  has  been  recorded  through  cost  or  disbursement,  the 
capability  to  update  or  correct  the  data  must  be  provided. 
Changes  specified  via  a source  document  will  be  recorded  as 
an  update  transaction.  Those  changes  made  as  a result  of 
erroneous  input  of  a data  element  will  be  defined  as  a 
correction  transaction.  Every  data  element  except  the  TA 
Number,  Trip  Number  (if  applicable) , type  of  travel 
activity,  and  Transportation  Request  Number  (if  it  is  a 
transportation  activity)  is  subject  to  an  update  or  change 
transaction . 

In£ut  - The  TA  Number,  Trip  Number  (if  applicable) , 
type  of  travel  activity,  and  Transportation  Request  Number 
(if  it  is  a transportation  activity)  will  identify  the 
unigue  data  element  set  to  which  the  update  or  correction 
will  be  made  and  are  required  input  data  elements.  Data 
elements  to  be  changed  are  input  as  reguired.  Figure  2.12-5 
shows  possible  data  element  changes  and  edits  required  for 
these  changes.  The  type  of  travel  activity  codes,  input 
data  element  relationships,  and  additional  edit  requirements 
are  shown  in  figure  2.12-2.  The  Travel  performance  data 
template  used  to  input  the  required  data  is  illustrated  in 
figure  2. 12-3. 


Data 

element 

Element 

required 

Source 

Error 

txpe 

* 

Tnput/Edit  requirements 

Error 

code 

1 As  of' 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Travel 

Authorization 

Number 

Yes 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  for  all  change  transactions.  The  first  char- 
acter must  be  alphabetic,  and  the  remaining  five 
must  be  numeric. 

cooo 

C001 

Trip  Number 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  to  be  applied 
to  a specific  Trip  Number  identified  to  a General 
Travel  Authorization.  Must  be  numeric. 

C010 

C011 

Transportation 
Request  Number 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  The  first  character  must  be 
alphabetic,  and  the  remaining  seven  must  be  numeric. 
See  figure  2.  12-2  for  additional  edits. 

C021 

Type  of 

travel 

activity 

Yes 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  for  all  change  transactions.  The  first  three 
digits  must  be  numeric,  and  the  fourth  must  be 
alphabetic.  See  figure  2. 12-2  for  additional  edits. 

C03  0 
C031 

Fund  Source 

Condition  -jl 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  the  value  1,  2,  or  3. 
See  figure  2. 12-2  for  additional  edits. 

B 1 36 
Cl  39 
C508 
C509 
C510 

Object  Class 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  a valid  Object  Class. 
See  figure  2.12—2  for  additional  edits. 

E 19  1 

Commitment, 
Obligation, 
and  Cost 
Dollar  Amount 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  as  a net  change  only  when  a change  transaction 
is  used  to  update  this  element.  Must  be  numeric  and 
not  egual  to  0. 

B661 

B667 

C410 

Disbursement 
rcllar  Amount 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  numeric. 

B641 

C410 

voucher 

number 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  numeric. 

B931 

B933 

Final  payment 

Conditional 

User  supplied 

Fatal 

Transaction  indicator.  Check  whether  an  update  or 
correction  applies  to  a final  payment  transaction- 

B080 

Figurp  2-12-5-  - Travel  performance  data  update  and  correction  input  and  edit  requirements. 


Data 

Element 

Error 

Error 

element 

required 

Source 

type 

Input/Edit  requirements 

code 

Payment  by 
others 

Conditional 

User  supplied 

Fatal 

Transaction  indicator.  Check  whether  an  update  or 
correction  applies  to  a payment  by  others  transaction. 

B081 

Reopening 

No 

None 

None 

Must  not  be  input  for  any  Travel  update  and  correction 
transaction- 

None 

Method  of 
Authority 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  a valid  MA  but  not  97. 

Bill 
B 1 1 5 

Program  Year 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  a valid  PY.  Also  must 
validated  with  FS  defined  for  travel  performance 
data  being  changed  or  with  updated  values  if  either 
or  both  are  changed  in  the  transaction. 

B121 
B 1 22 
C5O0 

Primary  Work 
Code 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  nine  digits. 

B 17 1 
B171 

Responsible 

Organization 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  a valid  RO . 

B201 

C509 

C510 

Performing 

Organization 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Positions  1 and  2 must  be 
alphabetic.  Positions  3 and  4 must  be  numeric. 
Must  be  a valid  Performing  Organization. 

B321 

Primary  Job 
Code 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  up- 
date this  element.  Must  be  numeric.  If  the  first 
digit  is  0 or  1,  must  be  a Centerwide  Job  Code. 

Also  validated  with  FS  and  Performing  Organization 
defined  for  travel  performance  data  being  changed  or 
with  updated  values  if  either  or  both  changed  in  the 
transaction- 

B330 

B331 

C509 

Secondary 
Job  Code 

Conditional 

Travel  docu- 
ment or 

Fatal 

input  only  when  a change  transaction  is  used  to 
to  update  this  element.  A Primary  Job  Code  must 

B340 

B341 

user  supplied  already  exist  for  travel  performance  data  being  B342 

changed  or  be  input  as  a part  of  the  transaction.  C510 

Must  be  numeric.  If  the  first  digit  is  G or 
1,  must  be  a Centerwide  Job  Code.  Also  validated 
with  FS  and  Performing  Organization. 


Figure  2.12-5.  - Travel  performance  data  update  and  correction  input  and  edit  requirements  (continued). 
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N) 


Data 

element 

Element 

required 

Source 

Error 

Name  code 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Travel  date 
(beginning) 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Travel  date 
(ending) 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Government 
Bill  of 
Lading 
number 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

For  changes 
only 

les 

User  supplied 

Fatal 

Injjut^Edit  requirements 


Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  he  a valid  name  code. 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  numeric  and  con- 
form to  all  normal  date  edits. 

Input  only  when  a change  transaction  is  used 
to  update  this  element.  Must  he  numeric  and 
conform  to  all  normal  date  edits. 

Input  only  when  a change  transaction  is  used  to 
update  this  element.  Must  be  alphanumeric. 


Transaction  modifier.  Input  as  either  'update' 
if  the  change  being  made  is  directed  by  documenta- 
tion or  'correction*  if  the  change  being  made  is 
because  of  erroneous  initial  input. 


Error 

code 


C041 


C051 


C061 

C062 

B42 1 


B062 


Figure  2.12-5.  - Travel  performance  data  update  and  correction  input  ana  edit  requirements  (concluded). 


Processing  - Processing  requirements  for  update  and 
correction  transactions  vary  according  to  the  data  elements 
being  changed.  Defining  the  transactions  to  change  existing 
data  specifies  that  a performance  data  record  exist  for  the 
designated  TA  Number,  Trip  Number  (if  applicable) , type  of 
travel  activity,  and  Transportation  Request  Number  (if  it  is 
a transportation  activity)  and  that  the  record  must  be  open. 
If  a performance  data  record  does  not  exist  or  if  the  record 
is  closed,  processing  must  be  halted  and  an  error  message 
provided.  For  those  elements  that  have  no  effect  on  the 
funds  availability  process  (PWC,  Performing  Organization, 
Primary  Job  Code,  Secondary  Job  Code,  start  date,  end  date, 
GBL  number,  and  voucher  number) , the  data  elements  can  be 
updated  directly  and  the  transaction  recorded  for  audit 
trail  purposes. 

Changes  to  the  dollar  fields  apply  to  either 
performance  through  cost  or  disbursement  and  have  an  effect 
on  the  Fund  Control  accounts  and,  thus,  have  more  extensive 
processing  requirements. 

• Performance  through  cost  dollar  change  - A decrease 
in  dollars  requires  that  the  dollar  amount  of  the 
decrease  be  subtracted  from  the  performance  data 
(commitment,  obligation,  and  cost)  and  also  from  the 
issues  of  the  funding  PNA  subaccount  entry.  A 
dollar  increase  requires  that  a funds  availability 
check  be  made  for  the  amount  of  the  increase. 

• Disbursement  dollar  change  - Any  adjustment  to  the 
disbursement  dollars  that  causes  the  disbursement 
dollars  to  exceed  the  commitment,  obligation,  and 
cost  dollars  in  the  performance  data  record  being 


changed  reguires  a funds  availability  check.  If  the 
balance  in  the  funding  PWA  account  entry  is 
sufficient,  the  PWA  account  entry  issues  are 
increased  by  the  additional  dollars  required,  the 
commitment,  obligation,  and  cost  dollars  are 
increased  by  a like  amount,  and  the  disbursement 
dollars  updated  by  the  input  dollars.  The  final 
payment  indicator  controls  the  processing 
requirements  when  the  updated  obligation  dollars 
would  be  less  than  the  commitment,  obligation,  and 
cost  dollars.  If  a final  payment  is  specified,  the 
disbursement  dollars  are  updated,  the  commitment, 
obligation,  and  cost  dollars  are  reduced  by  the 
amount  necessary  to  make  all  dollars  equal,  and  the 
funding  PWA  account  entry  issues  decreased 
(increasing  the  balance  for  that  entry) . If  the 
final  payment  is  not  specified,  only  the 
disbursement  dollars  must  be  updated. 

Changes  to  any  of  the  other  data  elements  (MA,  PY,  FS, 
RO,  and  Object  Class)  also  have  an  affect  on  the  Fund 
Control  accounts  and,  thus,  affect  the  PWA  account.  The 
entire  amount  must  be  subtracted  from  the  issues  of  the 
original  funding  PWA  account  entry,  the  availability  of 
funds  checked,  the  appropriate  PWA  account  entry  issues 
increased,  and  the  changed  data  element  posted. 

QUipuJ-  ” Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Travel  performance  data  update  and 
correction  transaction. 


2.12.1.4  ?£§Y§i_^lY‘H}£®  • An  advance  nay  be  made  to  a 
traveler  to  provide  funds  for  cash  payment  of  travel 
expenses.  When  the  advance  is  made,  the  Travel  Unit  must 
record  that  advance  amount  in  the  online  system  using  a 
Travel  Advance  Establishment  transaction. 

Upon  completion  of  a trip  or  a PCS  move,  the  advance 
must  be  liquidated.  The  completed  Travel  Voucher  reports 
all  expenses  incurred  and  shows  the  advance  dollars  to  be 
liquidated.  The  following  sections  discuss  the  input, 
processing,  and  output  requirements  of  the  Travel  Advance 
Establishment,  Travel  Advance  Liquidation,  and  Update  and 
Correction  transactions. 

2.12.1.4.1  Establishment:  Data  provided  on  the 
Application  and  Account  for  Advance  of  Funds,  Standard  Form 
1038,  received  by  the  Travel  Unit  must  be  recorded  and 
available  for  later  reference.  All  travel  advance  documents 
must  be  approved  at  the  same  time  that  the  travel  order 
undergoes  the  certification  of  funds  availability  process. 

Input  - Information  required  for  the  travel  advance 
establishment  is  user  supplied  information  derived  from 
Standard  Form  1038.  Input  data  elements  and  data  edits  that 
are  required  are  shown  in  figure  2.12-6.  Figure  2.12-7 
defines  the  template  required  for  input  of  these  data 
elements. 

Processing  - Initial  input  of  travel  advance 
establishment  first  requires  that  no  travel  advance 
establishment  dollars  exist  in  the  data  base  for  the  given 
TA  Number  and  Trip  Number  (if  applicable) . If  travel 
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Data 

element 

Element 

required 

Source 

Error 

'As  of* 
Date 

Optional 

Gser  supplied 

Fatal 

Travel 

Authorisation 

Humber 

User  supplied 

Fatal 

Trip  Number 

Conditional 

User  supplied 

Fatal 

Name  code 

Yes 

User  supplied 

Fatal 

Dollar 

Amount 

Yes 

Application 
and  account 
for  advance 
of  funds 

Fat  ai 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Establishment 
voucher  number 

Yes 

tfser  supplied 

Fatal 

Type  of 
liquidation 

No 

None 

Fatal 

Fo t changes 
only 

No 

None 

Fatal 

Reopening 

No 

None 

None 

Error 

ingut/Edit  requirements  code_ 

Date  providing  for  the  backdating  of  transactions-  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be 
numeric  and  conform  to  all  normal  date  edits. 

Input  for  all  Travel  Advance  Establishment  trans-  C000 

actions.  The  first  character  must  be  alphabetic,  C001 

and  the  remaining  five  must  be  numeric. 

Identifies  a specific  Trip  Humber  within  a General  C0 10 

Travel  Authorization.  Input  for  a General  Travel  CO 11 

Authorization.  Must  be  numeric. 

Input  for  all  Travel  Advance  Establishment  trans-  C040 

actions.  Must  be  a valid  name  code.  C041 

Input  for  all  Travel  Advance  Establishment  trans-  B6G0 

actions.  Must  be  numeric  and  not  equal  to  0.  B601 

5602 

Transaction  indicator.  Input  as  ■establishment1  B0 10 

for  all  Travel  Advance  Establishment  transactions.  B0 11 

Input  for  all  Travel  Advance  Establishment  trans-  C070 

actions.  Host  be  numeric.  C071 

Must  not  be  input  for  any  Travel  Advance  Establish-  BO 10 

ment  transaction-  B0 11 

Must  not  be  input  for  the  initial  Travel  Advance  Es-  B010 

tablishment  transaction.  B0 11 

M&St  not  be  .input  for  the  initial  Travel  Advance  Hone 

Establishment  transaction. 


Figure  2.12-6.  - Travel  Advance  Establishment  input  and  edit  requirements- 


♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  OF  /__/ 

♦♦♦♦TEMPLATE  NO.  P2  - TRAVEL  ADVANCE 

TRAVEL  AUTH  NO. TRIP  NO. NAME  CODE 

AMOUNT  $ , , . ± 

TYPE  OF  TRANSACTION:  ESTABLISHMENT  _ LIQUIDATION 

ESTABLISHMENT  VOUCHER  NO.  

TYPE  OF  LIQUIDATION: 

VOUCHER  DEDUCTION  _ VOUCHER  NO.  

CASH  COLLECTION  _ CD  N0o  

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 

REOPENING 


Figure  2.12-7 


Travel  Advance  template 


advance  establishment  dollars  do  exist,  processing  must  be 
halted  and  an  error  message  provided. 

Once  the  transaction  has  been  accepted  by  the  system, 
the  following  elements  must  be  recorded  in  the  data  base: 

• Travel  Authorization  Number 

• Trip  Number  (if  appplicable) 

• Name  code 

• Travel  advance  establishment  dollars 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  a Travel  Advance  Establishment  transaction. 

2.12.1.4.2  Liquidation:  Advances  for  travel  expenses 

must  be  liquidated  after  the  completion  of  a travel  or  a PCS 
activity.  One  of  two  methods  can  be  used  to  liquidate  a 
travel  advance:  a voucher  deduction  or  a cash  collection. 

Voucher  Deduction 

Input  - Information  from  travel  advance  liquidation  via 
voucher  deduction  is  derived  from  the  Travel  Voucher.  Input 
data  elements  and  data  edits  that  are  required  are  shown  in 
figure  2.12-8.  Figure  2.12-7  defines  the  template  required 
for  input  of  these  data  elements. 
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Data 

Element 

Error 

Error 

element 

required 

Source 

type 

Input/Edit  requirements 

code 

* As  of* 

Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B0 1 0 

B0 1 1 

Travel 

Authorization 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  Advance  liquidation  transactions. 
The  first  character  must  be  alphabetic,  and  the  re- 
maining five  must  be  numeric. 

cooo 

C001 

Trip  Number 

Conditional 

User  supplied 

Fatal 

Identifies  a specific  Trip  Number  within  a General 
Travel  Authorization.  Input  for  a General  Travel 
Authorization.  Must  be  numeric. 

C010 

C011 

Name  code 

No 

None 

Fatal 

Must  not  be  input  for  the  Travel  Advance  Liquidation 
transaction. 

C043 

Dollar 

Amount 

Yes 

User  supplied 
or  a 

collection 

voucher 

Fatal 

Input  for  all  Travel  Advance  Liquidation  transactions. 
Must  be  numeric  and  not  equal  to  0. 

B600 

B601 

B602 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Transaction  indicator.  Input  as  •liquidation*  for  all 
Travel  Advance  Liquidation  transactions. 

B0 1 0 

B0 1 1 

Establishment 
voucher  number 

No 

None 

Fatal 

Must  not  be  input  for  the  Travel  Advance  Liquidation 
transaction. 

C072 

Type  of 
liquidation 

Yes 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  for  all  Travel  Advance  Liquidation  transactions. 
For  voucher  deduction  liquidations,  must  specify 
•voucher  deduction*  and  input  the  voucher  number. 

The  voucher  number  must  be  numeric. 

B930 
B93 1 
B933 

For  changes 
only 

No 

None 

Fatal 

Must  not  be  input  for  the  initial  Travel  Advance 
Liquidation  transaction. 

B010 
B0 1 1 

Eeopening 

No 

None 

None 

Must  not  be  input  for  the  Travel  Advance  Liquidation 
transaction. 

None 

Figure  2.12-8.  - Travel  advance  liquidation  input  and  edit  requirements  - voucher  deduction 


Processing  - Processing  the  liquidation  of  a travel 
advance  via  a voucher  deduction  first  requires  that  travel 
advance  establishment  dollars  exist  for  the  specified  TA 
Number  and  Trip  Number  (if  applicable)  and  that  the  travel 
advance  is  open.  If  travel  advance  establishment  dollars  do 
not  exist  or  if  the  travel  advance  is  closed,  processing 
must  be  halted  and  an  error  message  provided.  Once  the 
transaction  has  been  accepted  by  the  system,  the  following 
elements  must  be  recorded  in  the  data  base: 

• Travel  advance  liquidation  dollars 

• Voucher  number 

• Closed  indicator  (if  liquidation  dollars  equal 
establishment  dollars) 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  a Travel  Advance  Liquidation  transaction. 

Cash  Collection 

In£ut  “ Information  from  travel  advance  liquidation  via 
cash  collection  is  derived  from  a Bill  of  Collection,  Form 
1114,  and  the  Daily  Cash  Receipts  report  received  by  the 
Travel  Unit.  The  Cash  Collection  Refund  transaction  for 
travel  advances  which  records  the  cash  amount  by 
appropriation  will  be  discussed  in  section  2.14,  Accounts 
Receivable  process.  Input  data  elements  and  data  edits  that 
are  required  are  shown  in  figure  2.12-9.  Figure  2.12—7 
defines  the  template  required  for  input  of  these  data 
elements. 
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Data 
ele sent 

Element 

required 

Source 

Error 

t££e_ 

Tn  put.  ,/Ed  it  requirements 

Error 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions.  In- 
put only  when  a transaction  date  other  thanthe  system 
date  is  desired.  When  input,  must  be  numeric  and  con- 
form to  all  normal  date  edits. 

B100 

E 101 

Travel 

Authorization 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  Advance  Liquidation  transactions. 
The  first  character  must  be  alphabetic,  and  the  re- 
maining five  must  be  numeric. 

cooo 

C001 

Trip  Number 

Conditional 

User  supplied 

Fatal 

Identifies  a specific  Trip  Number  within  a General 
Travel  Authorization.  Input  for  a General  Travel 
Authorization.  Must  be  numeric. 

C010 

con 

Name  code 

No 

None 

Fatal 

Bust  not  be  input  for  the  Travel  Advance  Liquidation 
transaction. 

C043 

Dollar 

Amount 

Yes 

User  supplied 
or  bill  of 
collection 

Fatal 

Input  for  all  Travel  Advance  Liquidation  transactions. 
Must  be  numeric  and  not  equal  to  0. 

B600 
B60 1 
B602 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Transaction  indicator.  Input  as  •liquidation*  for 
all  Travel  Advance  Liquidation  transactions. 

B010 

B011 

Establish  »ent 
voucher  number 

No 

None 

Fatal 

Must  not  be  input  for  the  Travel  Advance  Liquidation 
transaction. 

B932 

Type  of 
liquidation 

Yes 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Input  for  all  Travel  Advance  Liquidation  transactions. 
For  cash  collection  liquidation,  must  specify  ’cash 
collection*  and  input  the  certificate  of  deposit 
number.  The  first  two  characters  of  the  certificate 
of  deposit  number  must,  be  alphabetic,  and  the  remain- 
ing two  must  be  numeric. 

B940 

B941 

For  changes 
only 

No 

None 

Fatal 

Must  not  be  input  for  the  initial  Travel  Advance  Li- 
quidation transaction. 

B0 1 0 
B011 

Reopening 

No 

None 

None 

Must  not  be  input  for  the  Travel  Advance  Liquidation 
transaction. 

None 

Figure  2.12-9. 


- Travel  Advance  Liquidation  input  and  edit  requirements  - cash  collection. 


Processing  - Processing  the  liquidation  of  a travel 
advance  via  a Bill  of  Collection  and  a Daily  cash  Heceipts 
report  first  requires  that  travel  advance  establishment 
dollars  exist  for  the  specified  TA  Number  and  Trip  Number 
(if  applicable)  and  that  the  travel  advance  is  open.  If 
travel  advance  establishment  dollars  dt  not  exist  or  if  the 

travel  advance  is  closed,  processing  ,'ust  be  halted  and  an  ] 

error  message  provided.  Once  the  transaction  has  been  j 

accepted  by  the  system,  the  following  elements  must  be  j 

recorded  in  the  data  base:  } 

j 

• Travel  advance  liquidation  dollars  - j 

• Certificate  of  deposit  number 

• Closed  indicator  (if  liquidation  dollars  equal 
establishment  dollars) 

1 

; . 

To  satisfy  audit  trail  requirements,  the  transaction  j 

information  is  recorded  in  a transaction  history. 

""  Section  2.12.2  describes  the  standard  online  } 

responses  and  error  messages  that  are  required  in  the  \ 

processing  of  a Travel  Advance  Liquidation  transaction.  \ 

i 

J 

2.12.1.4.3  Update  and  correction:  After  initial  I 

travel  advance  establishment  or  liquidation  information  has  | 

been  recorded,  the  capability  to  update  or  correct  the  data  3 

must  be  provided.  Changes  specified  via  a source  document  j 

recorded  as  an  update  transaction.  Those  changes  j 

made  as  a result  of  erroneous  input  of  a data  element  will  I 

be  defined  as  a correction  transaction.  I 
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ORIGINAL  PASfi 
QF  POOR  QUAU 


Data  Element  Error 

element  required  Source  type 


■As  of*  Optional  User  supplied  Fatal 

Date 


Travel  Yes  Travel  docu-  Fatal 

Authorization  aent  or 

Number  user  supplied 

Trip  Number  Conditional  Travel  docu-  Fatal 

aent  or 
user  supplied 

Haae  code  Conditional  User  supplied  Fatal 


Dollar 

Amount 

Conditional 

Travel  docu- 
ment or 
user  supplied 

Fatal 

Type  of 
transaction 

Yes 

User  supplied 

Fatal 

Establishment 
voucher  number 

Conditional 

User  supplied 

Fatal 

Type  of 
liquidation 

Conditional 

User  supplied 

Fatal 

For  changes  Yes  ^ser  supplied  Fatal 

only 


Reopening  No  None  None 


| Figure  2.12-10.  - Travel  Advance 

l ' ' 

f ■ 


£ 1 

v ' 


Error 

Input/Edit  reguireaents  cgde_ 

Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

systea  date  is  desired.  When  input,  aust  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  change  transactions.  Bust  be  alpha-  COOO 

numeric.  The  first  character  must  be  alphabetic,  C001 

and  the  five  remaining  must  be  numeric. 

Input  only  when  a change  transaction  is  to  be  applied  C010 
to  a specific  Trip  Number  within  a General  Travel  C011 

Authorisation.  Bust  be  numeric. 

Input  only  when  a change  transaction  is  used  to  up-  C041 

date  this  element.  Bust  be  numeric  and  not  egual  C042 

to  0 . 

Input  as  a net  change  only  when  a change  transaction  B600 

is  used  to  update  this  element.  Bust  be  numeric  B601 

and  not  equal  to  0.  B602 

Input  for  all  change  transactions.  Transaction  indi-  B010 
cator.  Input  as  either  an  establishment  or  a ligui-  B0 11 

dation  transaction. 

Input  only  when  a change  transaction  is  used  to  update  C071 
this  element. 


Input  for  all  change  liquidation  transactions.  Input  B930 
as  either  a voucher  deduction  and  voucher  number  or  B931 

a cash  collection  and  a certification  of  deposit  B932 

number.  B933 

B940 

B941 

B942 


Transaction  modifier.  Input  as  either  » update*  if  the  B0 10 
change  being  made  is  directed  by  documentation  or  B0 11 

■correction*  if  the  change  being  made  is  because  of 
erroneous  initial  input. 

Bust  not  be  input  for  any  Travel  Advance  update  None 

and  correction  transaction. 


pdate  and  correction  input  and  edit  requirements. 


Input  - Information  required  for  a travel  advance 
update  or  correction  will  be  user  supplied  or  derived  from  a 
travel  document.  Input  data  elements  and  data  edits  are 
shown  in  figure  2.12-10.  Figure  2.12-7  defines  the  template 
required  for  input  of  these  data  elements. 

Processing  - An  update  or  correction  transaction  first 
requires  that  a travel  advance  record  exist  for  the 
specified  TA  Number  and  Trip  Number  (if  applicable)  and  the 
travel  advance  is  open.  If  a travel  advance  record  does  not 
exist  or  if  the  travel  advance  is  closed,  processing  must  be 
halted  and  an  error  message  provided. 

For  those  data  element  changes  not  associated  with  a 
dollar  change,  the  data  base  can  be  updated  for  the 
specified  TA  Number  and  Trip  Number  (if  applicable) . The 
following  data  elements  can  be  overlaid: 

• Name  code 

• Voucher  number 

• Certificate  of  deposit  number 

Changes  to  the  dollar  fields  apply  to  establishment 
dollars  o:c  liquidation  dollars  and,  thus,  have  more 
extensive  processing  requirements. 

• Establishment  dollar  changes  - A negative  dollar 
value  requires  that  the  dollar  amount  be  subtracted 
from  the  establishment  dollar  field.  The  result  of 
the  update  must  never  be  negative  nor  less  than  the 
liquidation  dollar  field.  If  this  condition  occurs, 
processing  must  be  halted,  the  update  must  not 
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occur,  and  an  error  message  must  be  provided.  A 
positive  dollar  value  adds  the  input  dollars  to  the 
establishment  dollar  field. 

• Liquidation  dollar  changes  - A negative  dollar  value 
requires  that  the  dollar  amount  be  subtracted  from 
the  liquidation  dollar  field.  The  result  of  the 
update  must  never  be  negative.  if  this  condition 
occurs,  processing  must  be  halted,  the  update  must 
not  occur,  and  an  error  message  must  be  provided. 

A positive  dollar  value  adds  the  input  dollars  to 
the  liquidation  dollar  field.  The  result  of  the 
update  must  never  be  greater  than  the  establishment 
dollar  field.  If  this  condition  occurs,  processing 
must  be  halted,  the  update  must  not  occur,  and  an 
error  message  must,  be  provided* 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  recorded  in  a transaction  history. 

Output  - section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  reguired  in  the 

processing  of  a Travel  Advance  update  and  correction 
transaction . 

2.12.1.5  Travel — a dva nce_miscel la neous_ope rations . A 

travel  advance  may  generate  three  types  of  Travel  Advance 
Miscellaneous  Operations  transactions  which  do  not  follow 
normal  processing  and  are  identified  as  the  following: 

• Cancelled  check  (travel  advance  check  cancelled) 
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Data  Element  Error 

elempnt  required  Source  tXE£_ 

•As  of  Optional  User  supplied  Fatal 

Date 


Travel  Yes  User  supplied 

Authorization 

Number 

Trip  Number  Conditional  User  supplied 


Fatal 


Fatal 


Dollar  Yes 

Amount 


User  supplied  Fatal 


Type  of  Yes 

miscellaneous 

operations 


User  supplied  Fatal 


i 


For  changes  No 

only 


Fatal 


Error 

Tnpni-/Edit  requirements  - — 

Date  providing  for  the  backdating  of  transactions.  BiOO 

Input  only  when  a transaction  date  other  than  the  fliui 

system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  Travel  Advance  Miscellaneous  Operations  C000 
transactions.  The  first  character  must  be  alphabetic,  C001 
and  the  remaining  five  must  be  numeric. 

Identifies  a specific  Trip  Number  within  a General  C010 

Travel  Authorization.  Input  for  a General  Travel  con 

Authorization.  Must  be  numeric. 

Input  for  all  Travel  Advance  Miscellaneous  Operations  B600 
transactions.  Must  be  numeric  and  not  egual  to  BbUi 


B931 
B932 
B933 
B941 
B942 
C400 
C«01 

Must  not  be  input  for  a Travel  Advance  Miscellaneous  None 
Operations  transaction - 


Transaction  modifier.  Input  one  of  the  following 
indicators  along  with  the  appropriate  number: 
cancelled  check  indicator  and  voucher  number,  bad 
check  indicator  and  certificate  of  deposit  number, 
or  writeoff  indicator  and  voucher  number. 


liscellaneous  Operations  input  and  edit  requirements. 


• Bad  check  (check  received  from  an  employee  to 
liquidate  a travel  advance) 

• Writeoff  (uncollectible  travel  advance  balance) 

2.12.1.5.1  Initial:  Data  provided  on  miscellaneous 

operations  travel  documents  received  in  the  Travel  Unit  must 
be  recorded  and  available  for  later  reference. 

Input  - Information  from  miscellaneous  operations 
travel  documents  requires  the  recording  of  nonbudgetary  data 
regarding  the  cancellation  of  a travel  advance  check,  the 
reverse  entry  of  a travel  advance  liquidation  due  to  a'  bad 
check  received,  or  a writeoff  of  an  uncollectible  travel 
advance  establishment  balance.  Input  data  elements  and  data 
edits  that  are  required  are  shown  in  figure  2.12-11.  Figure 
2. 12-12  illustrates  the  Travel  Advance  Miscellaneous 
Operations  template  used  to  input  the  required  data. 

Processing  - A Travel  Advance  Miscellaneous  Operations 
transaction  first  requires  that  a travel  advance  record 
exist  for  the  specified  TA  Number  and  Trip  Number  (if 
applicable) . If  a travel  advance  record  does  not  exist, 
processing  must  be  halted  and  an  error  message  provided. 
Once  the  transaction  has  been  accepted  by  the  system, 
processing  actions  will  occur  depending  on  the  type  of 
transaction . 

• Cancelled  check  - If  the  transaction  is  a cancelled 
check,  a reduction  of  the  travel  advance 
establishment  dollars  must  occur.  The  following 
elements  are  recorded  in  the  data  base: 

(1)  Cancelled  check  dollars 
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(2)  Cancelled  check  indicator 

(3)  Voucher  number 

• Bad  check  - If  the  transaction  is  a bad  check,  a 
reversal  of  the  liquidation  must  occur,  thereby 
reopening  the  travel  advance  establishment.  The 
dollar  amount  of  the  liquidation  field  must  be 
reduced.  The  following  elements  are  recorded  in  the 
data  base: 

(1)  Bad  check  dollars 

(2)  Bad  check  indicator 

(3)  Certificate  of  deposit  number 

• Writeoff  - If  the  transaction  is  a writeoff,  a 
liquidation  of  the  travel  advance  automatically 
occurs.  The  following  elements  are  recorded  in  the 
data  base: 

(1)  Writeoff  dollars 

(2)  Writeoff  indicator 

(3)  Voucher  number 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  reguired  in  the 
processing  of  a Travel  Advance  Miscellaneous  Operations 
transaction. 

2.12.1.5.2  Update  and  correction:  After  travel 

advance  miscellaneous  operations  data  has  been  recorded 
initially,  the  capability  to  update  or  correct  the  data  must 
be  provided.  Changes  specified  via  a source  document  will 
be  recorded  as  an  update  transaction.  Those  changes  made  as 
a result  of  erroneous  input  of  a data  element  will  be 
defined  as  a correction  transaction,  and  no  source  document 
is  associated  with  this  transaction.  Every  data  element 


2.12-36 


except  the  TA  Number  and  Trip  Number  (if  applicable)  is 
subject  to  an  update  or  correction  transaction. 

Input  - Information  required  for  a travel  advance 
miscellaneous  operations  update  or  correction  will  be  user 
supplied  or  derived  from  a travel  document.  Input  data 
elements  and  data  edits  are  shown  in  figure  2.12-13.  Figure 
2.12-12  illustrates  the  Travel  Advance  Miscellaneous 
Operations  template  used  to  input  the  required  data. 

Processing  - An  update  or  correction  transaction  first 
requires  that  a travel  advance  record  exist  for  ' the 
specified  TA  Number  and  Trip  Number  (if  applicable)  and  the 
travel  advance  is  open.  If  a travel  advance  record  does  not 
exist  or  if  the  travel  advance  is  closed,  processing  must  be 
halted  and  an  error  message  provided. 

For  those  data  element  changes  not  associated  with  a 
dollar  change,  the  data  base  can  be  updated  for  the 
specified  TA  Number  and  Trip  Number  (if  applicable) . The 
following  data  elements  can  be  overlaid: 

• Voucher  number 

• Certificate  cf  deposit  number 

Changes  to  the  dollar  field  apply  to  the  liquidation 
dollars  which  have  more  extensive  processing  requirements 
and  depend  on  the  Travel  Advance  Miscellaneous  Operations 
transaction  being  changed.  The  following  dollar  change 
processing  is  required. 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  P3  - TRAVEL  ADVANCE  MISC.  OPERATIONS 

TRAVEL  AUTH.  NO.  TRIP  NO. 

AMOUNT  $ , , . ± 

TYPE  OF  MISCELLANEOUS  OPERATION: 

CANCELLED  CHECK  _ VOUCHER  NO.  

BAD  CHECK  _ CD  NO. 

WRITEOFF  _ VOUCHER  NO.  

FOR  CHANGES  ONLY:  UPDATE  CORRECTION 


Figure  2. 12-12.  - Travel  Advance  Miscellaneous 
Operations  template. 


2. 12-38 


1 2-39 


Data 

element 

Element 

required 

Source 

Error 

Input/Edit  requirements 

Error 

code 

•As  of* 

Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

B100 
B 10 1 

Travel. 

Authorization 

Number 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  Advance  Miscellaneous  operations 
change  transactions.  The  first  character  must  be 
alphabetic,  and  the  remaining  five  must  be  numeric. 

cooo 

C001 

Trip  hnmber 

Conditional 

User  supplied 

Fatal 

Identifies  a specific  Trip  Number  within  a General 
Travel  Authorization.  Input  for  a General  Travel 
Authorization.  Must  be  numeric. 

C0 1 0 

con 

Dollar 

Amount 

Conditional 

User  supplied 

Fatal 

Input  only  when  a change  transaction  is  used  to  update 
this  element.  Must  be  numeric  and  not  egual  to  0. 

B600 

B601 

B602 

Type  of 

miscellaneous 

operations 

Yes 

User  supplied 

Fatal 

Transaction  modifier.  Input  one  of  the  following 
indicators  along  with  the  appropriate  number:  can- 

celled check  indicator,  bad  check  indicator,  or  write- 
off indicator.  Voucher  number  or  certificate  of  depo- 
sit number  input  only  when  the  change  transaction  is 
used  to  update  these  elements. 

B930 

B931 

B940 

B941 

C400 

C401 

For  changes 
only 

Yes 

User  supplied 

Fatal 

Transaction  modifier.  Input  as  either  •update*  if  the 
change  being  made  is  directed  by  documentation  or 
•corir  action*  if  the  change  being  made  is  because  of 

B062 

erroneous  initial  input. 


Figure  2.V2-13.  - Travel  Advance  Miscellaneous  Operations  update  and  correction  input  and  edit  requirements 


• Cancelled  check  update  or  correction  - & negative 

dollar  value  for  a cancelled  check  change 

transaction  results  in  an  increase  to  the  advance 
dollars  established  field  and  a decrease  to  the 
cancelled  check  dollar  field.  A positive  dollar 
value  for  a cancelled  check  change  transaction 
results  in  a decrease  to  the  advance  dollars 
established  field  and  an  increase  to  the  cancelled 
check  dollar  field. 

• Bad  check  update  or  correction  - A negative  dollar 
value  for  a bad  check  change  transaction  results  in 
an  increase  to  the  advance  dollars  liquidation  field 
and  a decrease  to  the  bad  check  dollar  field.  A 
positive  dollar  value  for  a bad  check  change 
transaction  results  in  a decrease  to  the  advance 
dollars  liquidation  field  and  an  increase  to  the  bad 
check  dollar  field. 

• Writeoff  update  or  correction  - A negative  dollar 
value  for  a writeoff  change  transaction  results  in  a 
decrease  to  the  advance  dollar  liquidation  field  and 
a decrease  to  the  writeoff  dollar  field.  A positive 
dollar  value  for  a writeoff  change  transaction 
results  in  an  increase  to  the  advance  dollars 
liquidation  field  and  an  increase  to  the  writeoff 
dollar  field. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 


2.12-40 


processing  of  a Travel  Advance  Miscellaneous  Operations 
transaction . 

2.12.1.6  Travel reopening  operations.  Data  provided 

on  travel  documents  received  in  the  Travel  Unit  may  pertain 
to  current  or  prior  years  activity  that  has  been  completely 
disbursed  and,  thus,  has  a closed  indicator.  These 
activities  must  be  reopened  in  order  to  process  additional 
data. 

2.12.1.6.1  Travel  performance  data  current  year 
reopening:  Travel  performance  data  current  year  reopening 
is  the  removal  of  the  closed  indicator  from  the  travel 
activity  performance  data  record  that  was  closed  during  the 
year  but  still  resides  on  the  data  base.  No  dollar  amount 
or  accounting  information  on  any  record  is  affected. 

Input  - The  Travel  Performance  Data  Current  Year 
Reopening  transaction  is  specified  by  the  reopening 
indicator  on  the  Travel  performance  data  template  shown  in 
figure  2.12-3.  The  transaction  can  be  entered  by  itself  or 
with  another  transaction. 

Processing  - The  first  processing  requirement  for  the 
travel  performance  data  current  year  reopening  specifies 
that  a performance  data  record  exist  for  the  input  TA 
Number,  Trip  Number  (if  applicable) , type  of  travel  activity 
code,  and  Transportation  Request  Number  (if  it  is  a 
transportation  activity)  and  that  the  closed  indicator  is 
set.  If  performance  data  does  not  exist  or  if  the 
performance  data  record  is  open,  processing  must  be  halted 
and  an  error  message  provided. 
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The  second  processing  requirement  specifies  the 
reopening  of  the  closed  performance  data  record  for  the  type 
of  travel  activity  being  processed  by  the  removal  of  the 
closed  indicator.  If  the  transaction  is  entered  with 
another  travel  performance  data  transaction,  the  reopening 
transaction  is  processed  first. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Travel  performance  data  current  year  reopening  and  reopening 
corrections  will  be  identified  in  the  transaction  history. 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Travel  Performance  Data  Current  Year 
Reopening  transaction. 

2.12.1.6.2  Travel  advance  current  year  reopening: 
Travel  advance  current  year  reopening  is  the  removal  of  the 
closed  indicator  from  the  travel  advance  record  that  was 
closed  during  the  year  but  still  resides  on  the  data  base. 
No  dollar  amount  or  accounting  information  on  any  record  is 
affected . 

Input  - The  Travel  Advance  Current  Year  Reopening 
transaction  is  specified  by  the  reopening  indicator  on  the 
Travel  Advance  template  shown  in  figure  2.12-7.  The 
transaction  can  be  entered  by  itself  or  with  another 
transaction. 
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travel  advance  data  record  exist  for  the  input  TA  Number  and 
Trip  Number  (if  applicable)  and  that  the  closed  indicator  is 
set.  If  travel  advance  data  does  not  exist  or  if  the  travel 
advance  is  open,  processing  must  be  halted  and  an  error 
message  provided.  The  second  processing  requirement 
specifies  the  reopening  of  the  closed  travel  advance  data 
record  by  the  removal  of  the  closed  indicator.  If  the 
transaction  is  entered  with  another  travel  advance 
transaction,  the  reopening  transaction  is  processed  first. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  is  also  recorded  in  a transaction  history. 
Travel  advance  current  year  reopening  and  reopening 
corrections  will  be  identified  in  the  transaction  history. 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  reguired  in  the 
processing  of  the  Travel  Advance  Current  Year  Reopening 
transaction. 


2.12.1.6.3  Travel  performance  data  prior  years 
reopening:  Data  provided  on  travel  documents  pertaining  to 
prior  years  activity  that  has  been  closed  in  previous  years 
must  be  reopened  for  processing.  Since  the  data  has  been 
closed  to  the  history  file,  a reopening  process  containing 
all  previously  recorded  information  must  be  entered. 

Input  - Information  that  must  be  input  for  all  prior 
years  travel  activity,  thus  reestablishing  a performance 
data  entry,  is  user  supplied  information  derived  from  the 
travel  history  reports.  Input  data  elements  and  data  edits 
required  are  shown  in  figure  2.12-14.  The  type  of  travel 
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Data 

element 

Element 

required 

Source 

Error 

type 

Input/Edit  requirements 

Error 

code_ 

'As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  Input,  oust  be  numeric 
and  confrom  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Travel 

Authorization 

Number 

les 

User  supplied 

Fatal 

Input  for  all  Travel  Performance  Data  Prior  Years 
Reopening  transactions.  The  first  character  must  be 
alphabetic,  and  the  remaining  five  must  be  numeric. 

cooo 

C001 

Trip  Number 

Conditional 

User  supplied 

Fatal 

Identifies  a specific  Trip  Number  within  a General 
Travel  Authorization.  Input  for  every  General  Travel 
Authorization.  Must  be  numeric. 

C010 

coil 

Transportation 

Reguest 

Number 

Conditional 

User  supplied 

Fatal 

Conditional  input  based  on  the  type  of  travel  activi- 
ty. Must  be  input  if  it  is  a transportation  activi- 
ty. The  first  character  oust  be  alphabetic,  and  the 
remaining  seven  must  be  numeric.  See  figure  2.12-2 
for  additional  edits. 

C020 

C021 

C022 

Type  of 

travel 

activity 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  Performance  Data  Prior  Years 
Reopening  transactions.  The  first  three  digits  must 
be  numeric,  and  the  fourth  must  be  alphabetic.  See 
figure  2.12-2  for  additional  edits. 

C030 

C031 

Fund  Source 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  Performance  Data  Prior  Years 

B120 

Q 4 

Reopening  transactions.  Must  be  the  value  1,  2 or  B136 

3.  See  figure  2.12-2  for  additional  edits.  B139 

C500 

C506 

C507 

C508 

C509 

C510 


Object  Class 

Yes 

User  supplied 

Fatal 

Input  for  all  Travel  Performance  Data  Prior  Years 
Reopening  transactions.  Must  be  a valid  Object 
Class.  See  figure  2.12-2  for  additional  edits. 

B 190 
B 19 1 

Method  of 
Authority 

Yes 

User  supplied 

Fatal 

Input  for 
Reopening 

all  Travel  Performance  Data  Prior  Years 
transactions.  Must  be  a valid  MA . 

B 1 1 0 
Bill 
B115 

Program  Year 

Yes 

User  supplied 

Fatal 

Input  for 
Reopening 
validated 

all  Travel  Performance  Data  Prior  Years 
transactions.  Must  be  a valid  PY.  Also 
with  FS. 

B 120 
B121 
C500 
C508 

Figure  2.12-14.  - Travel  Performance  Data  Prior  Years  Reopening  input  and  edit  reguirements. 


Error 

ti£e_ 


v 


Input/Edit  requirements 


Error 

code 


Fatal  input  for  all  Travel  Performance  Data  Prior  Years  B170 

Reopening  transactions.  Must  be  nine  digits.  B174 

Fatal  Input  for  all  Travel  performance  Data  Prior  Years  B200 

Reopening  transactions.  Must  be  a valid  BO.  B20 

Fatal  Input  for  all  Travel  Performance  Data  Prior  Years  B320 

Reopening  transactions.  Bust  be  a valid  Perform-"  C506 

ing  Organization.  C507 

C509 

C510 


Fatal  Input  if  applicable.  Bust  be  nuaerxc.  If  the  first  B330 

digit  is  0 or  1,  nust  be  a .alid  Centermde  Job  Code.  B331 
Also  validated  with  FS  and  Performing  Organization.  C506 

Fatal  input  if  applicable.  Must  be  numeric.  If  the  first  B340 

digit  is  0 or  1,  must  be  a valid  Centermide  Job  Code.  B3U1 
Also  validated  with  FS  and  Performing  Organization.  B342 

C510 

Fatal  Input  for  all  Travel  Performance  Data  Prior  Years  C040 

Reopening  transactions.  Bust  be  a valid  name  code.  C041 

Fatal  Input  for  all  Travel  Performance  Data  Prior  Years  C050 

Reopening  transactions.  Bust  be  numeric  and  con-  COST 

fora  to  all  date  edits. 

Fatal  Input  for  all  Travel  Performance  Data  Prior  Years  C060 

Reopening  transactions.  Bust  be  numeric  and  con-  C061 

form  to  all  date  edits.  CUb^ 

Fatal  Conditional  input  based  on  the  type  of  travel  B421 

. - - . x.  4-1.0  ronnan  inn  Fit  » chi  nipflt  Of  a 


activity.  Input  for  the  reopening  of  a shipment  of  a 
household  goods  activity  if  the  shipment  is  by  GEL. 


Fatal  Input  for  all  Travel  Performance  Data  Prior  Years  B660 

Reopening  transactions.  Bust  be  numeric.  Bool 

B662 


Fatal  Transaction  modifier.  Specified  only  when  the  Rone 

transaction  is  a correction. 


Data  Prior  Years  Reopening  input  and  edit  requirements  (concluded) . 


activity  codes,  specified  data  element  relationships,  and 
additional  edit  requirements  are  shown  in  figure  2.12-2. 
Figure  2.12-15  defines  the  template  required  for  input  of 
these  data  elements. 

Travel  entries  will  require  the  input  of  a transaction 
for  each  travel  activity  to  be  reopened  and  the  user  input 
of  the  complete  set  of  accounting  information  for  each 
transaction . 

Processing  - The  first  processing  requirement  for 
travel  prior  years  reopening  activity  requiring  the 
recording  of  additional  performance  data  specifies  that  no 
performance  data  can  already  exist  on  the  current  open  file 
for  the  input  TA  Number,  Trip  Number  (if  applicable) , type 
of  travel  activity  code,  and  Transportation  Request  Number 
(if  it  is  a transportation  activity) . If  performance  data 
does  exist,  processing  must  be  halted  and  an  error  message 
provided . 

The  second  processing  requirement  specifies  the 
reestablishment  of  a performance  data  record  for  the  type  of 
travel  activity  being  processed  for  a travel  order  (per 
diem,  transportation,  rental  car,  or  excess  baggage)  or  a 
PCS  [per  diem  (employee  and  dependents),  househunting, 
temporary  quarters,  sale  of  real  estate,  purchase  of  real 
estate,  movement  of  household  goods,  or  miscellaneous 
expense  ]. 


The  following  data  elements  must  be  included  for  the 
reopening  transaction. 


♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  P4  - TRAVEL  PERFORMANCE  REOPENING 

TRAVEL  AUTH  NO. TRIP  NO.  TRANS  REQUEST  NO.  

TYPE  OF  TRAVEL  ACTIVITY  FS  OBJECT  CLASS  

HA PY  PWC RESP  ORG  __  PERF  ORG 

PRIMARY  JOB  CODE SECONDARY  JOB  CODE . NAME  CODE 

TRAVEL  DATES:  START / /_  END  / / GBL  NO. 

REOPENING  $ , , . ± 

CORRECTION  _ 


Figure  2. 12-15 


Travel  Performance  Data  Reopening  template 


• Travel  Authorization  Number 

• Trip  Number  (if  applicable) 

• Type  of  travel  activity  code 

• Transportation  Request  Number  (if  it  is  a transpor- 
tation activity) 

• Fund  Source 

• Object  Class 

• Reopening  dollars  (Commitment,  obligation.  Cost  and 
Disbursement) 

• Method  of  Authority 

• Program  Year 

• Primary  Work  Code 

• Responsible  Organization 

• Performing  Organization 

• Primary  Job  Code  (if  provided) 

• Secondary  Job  Code  (if  provided) 

• Name  code 

• Start  date 

• End  date 

• Government  Bill  of  Lading  number  (if  applicable) 

To  satisfy  audit  trail  requirements,  the  transaction 
must  be  recorded  in  a transaction  history.  Travel 
performance  data  prior  years  reopening  and  reopening 
corrections  will  be  identified  in  the  transaction  history. 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Travel  Performance  Data  Prior  Years 
Reopening  transaction. 


2.12.1.6.4  Travel  advance  prior  years  reopening: 
Data  provided  on  travel  documents  pertaining  to  prior  years 
advance  activity  that  has  been  closed  in  previous  years  must 
be  reopened  for  processing.  Since  the  data  has  been  closed 
to  the  history  file,  a reopening  process  containing  all 
previously  recorded  information  must  be  entered. 

Input  - Information  that  must  be  input  for  all  prior 
years  travel  advances,  thus  reestablishing  a travel  advance 
data  entry,  is  user  supplied  information  derived  from  the 
travel  history  reports.  Input  data  elements  and  data  edits 
required  are  shown  in  figure  2.12-16.  Figure  2.12-17 
defines  the  template  required  for  input  of  these  data 
elements. 

Processing  - The  first  processing  requirement  for  the 
travel  advance  prior  years  reopening  record  requiring  the 
recording  of  additional  travel  advance  data  specifies  that 
no  travel  advance  data  can  already  exist  on  the  current  open 
file  for  the  input  TA  Number  and  Trip  Number  (if 
applicable) . If  travel  advance  data  does  exist,  processing 
must  be  halted  and  an  error  message  provided. 

The  second  processing  requirement  specifies  the 
reestablishment  of  a travel  advance  data  record.  The 
following  data  elements  must  be  included  for  the  reopening 
transaction : 

• Travel  Authorization  Number 

• Trip  Number  (if  applicable) 

• Name  code 

• Reopening  dollars  (establishment  and  liquidation) 
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Data 

element 

Element 

required 

Source 

Error 

type 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Travel 

Authorization 

Number 

Yes 

User  supplied 

Fatal 

Trip  Number 

Conditional 

User  supplied 

Fatal 

Name  code 

No 

None 

Fatal 

Reopening 

dollars 

Yes 

User  supplied 

Fatal 

Correction 

Optional 

User  supplied 

Fatal 

Error 

Jnput/Edit  requirements  code 

Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be  numeric 
and  conform  to  all  normal  date  edits. 

Input  for  all  Travel  Advance  Prior  Years  Reopening  C000 

transactions.  The  first  character  must  te  alphabetic,  C001 
and  the  remaining  five  must  be  numeric. 

Identifies  a specific  Trip  Number  within  a General  CO  1C* 

Travel  Authorization.  Input  for  every  General  Travel  C011 
Authorization.  Bust  be  numeric. 

Input  for  all  Travel  Advance  Prior  Years  Reopening  C043 

transactions.  The  first  character  must  be  alphabetic, 
and  the  remaining  five  must  be  numeric. 


B600 

B601 

B602 

None 


Prior  Years  Reopening  input  and  edit  requirements. 


Input  for  all  Travel  Advance  Prior  Years  Reopening 
transactions.  Must  be  numeric. 


Transaction  modifier.  Specified  only  when  transaction 
is  a correction. 


♦♦♦♦IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  P5  _ TRAVEL  ADVANCE  REOPENING 

TRAVEL  AUTH  NO.  TRIP  NO.  NAME  CODE 

REOPENING  $ , , . ± 

CORRECTION 


Figure  2. 12-17 


Travel  Advance  Reopening  template 


To  satisfy  audit  trail  requirements,  the  transaction  is 
also  recorded  in  a transaction  history.  Travel  advance 
prior  years  reopening  and  reopening  corrections  will  be 
identified  in  the  transaction  history. 

Output  - Section  2.12.2  describes  the  standard  online 
responses  and  error  messages  that  are  required  in  the 
processing  of  the  Travel  Advance  Prior  Years  Reopening 
transaction. 


2.12.2  Output  Message  Requirements 

Figures  2.12-18  through  2.12-21  contain  a list  of 
output  message  requirements.  Figure  2.12-22  contains  a 
correlation  of  output  messages  by  travel  process 
transaction. 

2.12.3  Inquiry  Requirements 

Figure  2.12-23  contains  a list  of  inquiry  input  data 
elements  and  response  data  elements  required  for  the  travel 
process. 

2.12.4  Report  Requirements 

Section  2.19.4  lists  the  travel  performance  report 
requirements.  The  travel  reports  reflect  travel  performance 
activity  at  various  phases  along  with  the  travel  status  of 
orders  required  for  the  Travel  Unit.  The  following  reports 
are  included. 
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Code  Hessage 

****  TRAVEL  PERFORMANCE  THRU  COST  TRANSACTION-INITIAL 

****  TRAVEL  PERFORMANCE  THRU  COST  TRANSACTION-UPDATE 

****  TRAVEL  PERFORMANCE  THRU  COST  TRANSACTION-CORRECTION 

****  TRAVEL  PERFORMANCE  DISBURSEMENT  TRANSACTION 

****  TRAVEL  PERFORMANCE  REOPENING  PRIOR  YEAR-INITIAL 

****  TRAVEL  PERFORMANCE  REOPENING  PRIOR  YEAR-CORRECTION 

****  TRAVEL  ADVANCE  ESTABLISHED  TRANSACTION 

****  TRAVEL  ADVANCE  LIQUIDATION  TRANSACTION 

****  TRAVEL  ADVANCE  CANCELLED  CHECK  TRANSACTION 

****  TRAVEL  ADVANCE  BAD  CHECK  TRANSACTION 

****  TRAVEL  ADVANCE  WRITEOFF  TRANSACTION 

****  TRAVEL  ADVANCE  REOPENING  PRIOR  YEAR-INITIAL 

****  TRAVEL  ADVANCE  REOPENING  PRIOR  YEAR-CORRECTION 

B 0 1 0 TYPE  OF  TRANSACTION  NOT  SPECIFIED 

B0 1 1 MULTIPLE  TYPES  OF  TRANSACTION  SPECIFIED 

B062  BOTH  UPDATE  AND  CORRECTION  MUST  NOT  BE  SPECIFIED 

B 080  FINAL  PAYMENT  MUST  NOT  BE  SPECIFIED 

B081  PAYMENT  BY  OTHERS  MUST  NOT  BE  SPECIFIED 

B090  TYPE  OF  LIQUIDATION  NOT  SPECIFIED 

B 09 1 MULTIPLE  TYPES  OF  LIQUIDATION  SPECIFIED 

C400  TYPE  OF  MISC  OPERATION  NOT  SPECIFIED 

C401  MULTIPLE  TYPES  OF  MISC  OPERATION  SPECIFIED 

C410  BOTH  C/O/C  $ AND  DISBURSEMENT  $ MUST  NOT  BE  INPUT 

Figure  2.12-18.  - Travel  transaction-begun  messages. 


Code  Message 

AOOO  TRANSACTION  COMPLETE 

Figure  2.12-19.  - Travel  transaction- 
complete  messages. 
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Cqde  Message 

B 1 00  'AS  OF'  DATE  INVALID 

B 1 01  'AS  OF'  DATE  MOST  BE  PRIOR  TO  SYSTEM  DATE  / ./. 

Bl 10  MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 1 5 MA  MOST  NOT  BE  97 

B 1 1 8 MA  MOST  BE  BLANK 

Bl 20  PY  NOT  ENTERED 

B 1 21  PY  INVALID 

B124  PY  MOST  BE  BLANK 

B130  FS  NOT  ENTERED 

B136  FS  MOST  BE  AN  RSPM  FOND  SOORCE 

B 1 39  FS  INVALID 

B 1 41  FS  MOST  BE  BLANK 

B 1 70  PWC  NOT  ENTERED 

B171  PWC  INVALID 

B 174  PWC  MOST  BE  9 DIGITS 

B 1 75  PWC  MOST  BE  BLANK 

B 1 90  OBJECT  CLASS  NOT  ENTERED 

B 1 91  OBJECT  CLASS  INVALID 

B 1 92  OBJECT  CLASS  MOST  BE  BLANK 

B200  RESPONSIBLE  ORGANIZATION  NOT  ENTERED 

B201  RESPONSIBLE  ORGANIZATION  INVALID 

B2 05  RESPONSIBLE  ORGANIZATION  MOST  BE  BLANK 

B320  PERFORMING  ORGANIZATION  NOT  ENTERED 

B321  ' PERFORMING  ORGANIZATION  INVALID 

B324  PERFORMING  ORGANIZATION  MOST  BE  BLANK 

B330  PRIMARY  JOB  CODE  INVALID 

B331  PRIMARY  JOB  CODE  MOST  BE  CENTERWIDE  JOB  CODE 

B333  PRIMARY  JOB  CODE  MOST  BE  BLANK 

B3 40  SECONDARY  JOB  CODE  INVALID 

B341  SECONDARY  JOB  CODE  MOST  BE  BLANK 

B342  SECONDARY  JOB  CODE  MOST  BE  CENTER WIDE  JOB  CODE 

B421  GBL  NUMBER  INVALID 

Figure  2.12-20.  - Travel  data  element  edit  error  messages. 
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Code 

B422  GBL  NUMBER  MUST  BE  BLANK 

B600  $ AMOUNT  NOT  ENTERED 

B601  $ AMOUNT  INVALID 

B602  $ AMOUNT  MUST  NOT  BE  ZERO 

B640  DISBURSEMENT  $ NOT  ENTERED 

B64 1 DISBURSEMENT  $ INVALID 

B645  DISBURSEMENT  $ MUST  BE  BLANK 

B660  C/O/C  $ NOT  ENTERED 

B661  C/O/C  $ INVALID 

B665  C/O/C  $ MUST  BE  BLANK 

B662  C/O/C  S MUST  NOT  BE  ZERO 

B930  VOUCHER  NUMBER  NOT  ENTERED 

B931  VOUCHER  NUMBER  INVALID 

B932  VOUCHER  NUMBER  MUST  BE  BLANK 

B933  VOUCHER  NUMBER  MUST  BE  GREATER  THAN  ZERO 

B940  CD  NUMBER  NOT  ENTERED 

B941  CD  NUMBER  INVALID 

B942  CD  NUMBER  MUST  BE  BLANK 

C000  TRAVEL  AUTHORIZATION  NUMBER  NOT  ENTERED 

C001  TRAVEL  AUTHORIZATION  NUMBER  INVALID 

C010  TRIP  NUMBER  INVALID 

C011  TRIP  NUMBER  MUST  BE  GREATER  THAN  ZERO 

C020  TRANSPORTATION  REQUEST  NUMBER  NOT  ENTERED  . 

C021  TRANSPORTATION  REQUEST  NUMBER  INVALID 

C 022  TRANSPORTATION  REQUEST  NUMBER  MUST  BE  BLANK 

C030  TYPE  OF  TRAVEL  ACTIVITY  NOT  ENTERED 

C031  TYPE  OF  TRAVEL  ACTIVITY  INVALID 

C 040  NAME  CODE  NOT  ENTERED 

C041  NAME  CODE  INVALID 

C043  NAME  CODE  MUST  BE  BLANK 

C050  BEGINNING  DATE  NOT  ENTERED 

C 051  BEGINNING  DATE  INVALID 

Figure  2.12-20.  - Travel  data  element 
edit  error  messages  (continued) . 
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Code  Message 

C052  BEGINNING  DATE  MOST  BE  BLANK 
C060  ENDING  DATE  NOT  ENTERED 

C061  ENDING  DATE  INVALID 

C062  ENDING  DATE  MOST  NOT  BE  PRIOR  TO  BEGINNING  DATE 
C063  ENDING  DATE  MOST  BE  BLANK 

C070  ESTABLISHMENT  VOOCHER  NOMBER  NOT  ENTERED 
C 07 1 ESTABLISHMENT  VOOCHER  NOMBER  INVALID 
C072  ESTABLISH*!  1ST  VOOCHER  NOMBER  MOST  BE  BLANK 

C500  PY  FS  COMBINATION  INVALID 

C506  FS,  PERF  ORG,  PRIMARY  JOB  CODE  COMBINATION  INVALID 
C507  FS,  PERF  ORG,  SECONDARY  JOB  CODE  COMBINATION  INVALID 
C508  PY  FS  COMBINATION  INVALID 

C509  FS  , PERF  ORG  , PRIMARY  JOB  CODE  COMBINATION  INVALID 

C5 1 o FS  , PERF  ORG  , SECONDARY  JOB  CODE  COMBINATION  INVALID 


Figure  2.12-20.  - Travel  data  element 
edit  error  messages  (concluded)  . 
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Code 

D202 

D203 

D210 

D211 

D212 

D 1 40 
D 1 42 

D 1 43 

D200 
D20 1 


Message 

C/O/C  $ LESS  THAN  DISBURSEMENT  $ 

TRAVEL  AUTH  NO. TRIP  NO. 

TYPE  OF  TRAVEL  ACTIVITY  TRANS  REQUEST  NO. 

C/O/C  $ , , . DISBURSEMENT  

UPDATE  , , . 

C/O/C  $ INSUFFICIENT 

TRAVEL  AUTH  NO. TRIP  NO. 

TYPE  OF  TRAVEL  ACTIVITY  TRANS  REQUEST  NO. 

C/O/C  $_, , , UPDATE  , , 

TRAVEL  ADVANCE  RECORD  NOT  FOUND 

TRAVEL  AUTH  NC.  TRIP  NO. 

TRAVEL  ADVANCE  RECORD  ALREADY  EXISTS 

TRAVEL  AUTH  NC. TRIP  NO.  

TRAVEL  ADVANCE  LIQUIDATION  $ EXCEEDS  ESTABLISHED  $ 

TRAVEL  AUTH  NO. TRIP  NO. 

ESTABLISHED  $_, , , . LIQUIDATION  $ 

UPDATE  $_, , , . 

PWA  RECORD  NOT  FOUND 

MA PY FS RO PWC 

OBJECT  CLASS CARRIER  ID SUB  ID  

PWA  ISSUES  INSUFFICIENT 

MA PY FS RO PWC  

OBJECT  CLASS CARRIER  ID SUB  ID  

ISSUES  $_, , , . UPDATE  , , ._ 

PWA  BALANCE  INSUFFICIENT  TO  INCREASE  ISSUES 

MA PY FS RO  PWC 

OBJECT  CLASS  CARRIER  ID  SUB  ID  

BALANCE  $_, , UPDATE  , . 

TRAVEL  PERFORMANCE  DATA  RECORD  NOT  FOUND 

TRAVEL  AUTH  NO. TRIP  NO. 

TYPE  OF  TRAVEL  ACTIVITY  TRANS  REQUEST  NO. 

TRAVEL  PERFORMANCE  DATA  RECORD  ALREADY  EXISTS 
TRAVEL  AUTH  NC. TRIP  NO. 

TYPE  OF  TRAVEL  ACTIVITY  TRANS  REQUEST  NO. 

. - Travel  processing  error  messages. 
2.12-57 


Figure  2.12-21 


Code  Message 

D213  TRAVEL  ADVANCE  ESTABLISHED  $ INSUFFICIENT 

TRAVEL  AUTH  NO. TRIP  NO. 

ESTABLISHED  , , . UPDATE  , 

D214  TRAVEL  ADVANCE  LIQUIDATION  $ INSUFFICIENT 

TRAVEL  AUTH  NC. TRIP  NO. 

LIQUIDATION  , . UPDATE  $_, , 

D215  TRAVEL  ADVANCE  BAD  CHECK  $ INSUFFICIENT 

TRAVEL  AUTH  NC. TRIP  NO.  _ 

BAD  CHECK  $_, , . UPDATE  , 

D216  TRAVEL  ADVANCE  WRITEOFF  $ INSUFFICIENT 
TRAVEL  AUTH  NO. TRIP  NO. 

WRITEOFF  , , . UPDATE  $_, , , 

D217  TRAVEL  PERFORMANCE  RECORD  MUST  BE  CLOSED 
TRAVEL  AUTH  NC. TRIP  NO. 

TYPE  OF  TRAVEL  ACTIVITY  TRANS  REQUEST  NO. 


Figure  2.12-21 


Travel  processing  error  messages  (concluded) 
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Travel  performance  data 

Travel  performance  through  cost-initial 

Per  die®  activity 

Transportation  activity 

Shipment  of  household  goods  activity 

All  other  activities 

Travel  performance  disbursement-initial 

Local  aileage  activity 
All  other  activities 
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per  diem  activity 

Transportation  activity 

Shipment  of  household  goods  activity 

Local  mileage  activity 

All  other  activities 

Travel  advance 

Travel  advance  established-initial 
Travel  advance  liguidation-initial 
Update/Correction 
Miscellaneous  operations 
Initial 

Opdate/Correction 
Travel  reopening 

Travel  performance  data  current  year 
reopening 

Travel  advance  data  current  year 
reopening 

Travel  performance  data  prior  year 
reopening 

Initial 

Correction 
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Initial 

Correction 
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Figure  2.12-22,  - Travel  messages  by  transaction. 
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Travel  performance  data 

Travel  performance  through  cost-initial 

Per  diem  activity 

Transportation  activity 

Shipment  of  household  goods  activity 

All  other  activities 

Travel  performance  disbursement-initial 

LOcal  mileage  activity 
All  other  activities 

Update/Correction 

Per  diem  activity 

Transportation  activity 

Shipment  of  household  goods  activity 

Local  mileage  activity 

All  other  activity 

Travel  advance 

Travel  advance  established-initial 
Travel  advance  liquidation-initial 
Opdate/Correction 
Bxscellaneous  operations 
Initial 

Update/Correction 
Travel  reopening 

Travel  performance  data  current  year 
reopening 

Travel  advance  data  current  year 
reopening 

Travel  performance  data  prior  year 
reopening 

Initial 

Correction 

Travel  advance  data  prior  year  reopening 

initial 

Correction 
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Figure  2.12-22.  - Travel  messages  by  transaction  (continued) 
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Figure  2.12-22.  - Travel  messages  by  transaction  (continued) 


12-62 


He s sage 


Transaction 


Travel  performance  data 

Travel  perforiance  through  cost-initial 

Transportation  activity 

Shipment  of  household  goods  activity 

All  other  activities 

Travel  performance  disbursement-initial 

Local  mileage  activity 
All  other  activities 

Opdate/Correction 

Per  diem  activity 

Transportation  activity 

Shipment  of  household  goods  activity 

Local  mileage  activity 

All  other  activities 

Travel  advance 

Travel  advance  established— initial 
Travel  advance  liguidation-initial 
Update/Correction 
Hiscellaneous  operations 
Initial 

Update/Correction 
Travel  reopening 

Travel  performance  data  current  year 
reopening 

Travel  advance  data  current  year 
reopening 

Travel  perfornance  data  prior  year 
reopening 

Initial 

Correction 

Travel  advance  data  prior  year  reopening 

Initial 

Correction 


.cccccccccc 

0 4 4 4 5 5 5 5 5 5 

700100  0 001 
201  00678  9 0 


XXX 


XXX 
X X X 


ddddddddd 
1 1 1 2 2 2 2 2 2 
4 4 4 0 0 0 0 1 1 
0 2 3 0 1 2 3 0 1 


XXX  X 

XXX  X 

XXX  X 

XXX  x 


X X X X X 

X X X X X 


x x X X X X X X XX 

x X X X X X X X XX 

X XX  X X XXX  XX 

x XXXXXXX  XX 

x XXXXXXX  XX 


D 

2 

1 

7 


X x 

X XXX 

X X X X X X 

X X X X X X 

X 


2.12-22,  - Travel  messages  by  transaction  (concluded). 


Inquiry  description 


Type 


Input  data  elements 


Timing 


Status  of  travel 
performance  data 


Sufficient  funds  to 
commit 


Travel  performance 
summary  by  Travel 
Authorization  Humber r 
Trip  Number,  and 
type  of  travel  activity 


Travel  performance 
summary  by  Travel 
Authorization  Number 
and  Trip  Number 


Item  Travel  Authorization  Immediate 

Number 

Trip  Number  (if  ap- 
plicable) 

Type  of  travel 
activity 

Transportation  Reguest 
Number  (if  applicable) 


Item  Method  of  Authority  Immediate 

Program  Year 
Fund  Source 

Responsible  organization 
Object  Class 
Dollar  Amount 


Summary  Travel  Authorization  Immediate 

Number 
Trip  Number 

Type  of  travel  activity 


Summary  Travel  Authorization 

Number 
Trip  Number 


Immediate 


Travel  Authorization  Number 
Trip  Number  (if  applicable) 

Type  of  travel  activity 
Transportation  Reguest  Number 
, (if  applicable) 

Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Object  Class 
Name  code 

Performing  Organization 
GBL  number  (if  applicable) 

Start  date 
End  date 

Primary  Job  Code 

Secondary  Job  Code 

Accounts  Receivable  balance 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 
Last  activity  information 

Method  of  Authority 
Program  Year 
Fund  Source 

Responsible  Organization 
Funding  Object  Class 
Message: 

•Dollars  are  available'  or 
•Dollars  are  not  available1 
PHA  balance 

Travel  Authorization  Number 
Trip  Number 

Type  of  travel  activity 

Accounts  Receivable  balance 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 

Travel  Authorization  Number 
Trip  Number 

Accounts  Receivable  balance 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 


Figure  2.12-23.  - Travel  inquiry  requirements. 


Inquiry  description 


Type 


Input  data  elements 


Timing 


Response  data  elements 


Travel  performance 
summary  by  Travel 
Authorization 
Number 


Travel  performance 
summary  by  Travel 
Authorization  Number 
and  type  of  travel 
activity 


Travel  performance 
summary  by  type 
of  travel  activity 


Travel  performance 
grand  total 


Status  of  Travel 
Advance 


Travel  Advance 
summary  by 

Travel  Authorization 
Number 


Summary  Travel  Authorization  Immediate 

Number 


Summary  Travel  Authorization  Immediate 

Number 

Type  of  travel  activity 


Summary  Type  of  travel  activity  Immediate 


Summary  None  required 


Same  Day 


Item  Travel  Authorization  Immediate 

Number 

Trip  Number  (if  ap- 
plicable) 

Voucher  number 


Summary  Travel  Authorization  Immediate 

Number 


Travel  Authorization  Number 

Accounts  Receivable  balance 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 

Travel  Authorization  Number 

Type  of  travel  activity 

Accounts  Receivable  balance 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 

Type  of  travel  activity 

Accounts  Receivable  balance 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 

Travel  Authorization  Number 
Trip  Number  (if  applicable) 

Name  code 
Voucher  number 
Establishment 

Voucher  deduction  and  number 
Cash  collection  and  certificate 
of  deposit 
Outstanding  balance 
Cancelled  check  balance 
Bad  check  balance 
Writeoff  balance 
Last  activity  information 

Travel  Authorization  Number 

Name  code 

Establishment 

Voucher  deduction 

Cash  collection 

Outstanding  balance 


Figure  2.12-23.  - Travel  inquiry  requirements  (continued) 


Travel  Advance 
grand  total 


Travel  status 
by  employee 


Status  of  trans- 
portation reguest 


Input  data  elements 


Timing 


Response  data  elements 


Summary  None  required 


Same  Day  Establishment 

Voucher  deduction 
Cash  collection 
Outstanding  balance 


List 


List 


Name  code 


Transportation  Reguest 
Number 


Immediate  Employee  name 

Name  code 

Travel  Authorization  Number 
Trip  Number  (if  applicable) 

Type  of  travel  activity 
Transportation  Request  Number 
(if  applicable) 

GBL  number  (if  applicable) 

Start  date 
End  date 

Accounts  Receivable  balance 

Advance  balance 

Commitment 

Obligation 

Cost 

Disbursement 

Immediate  Travel  Authorization  Number 

Trip  Number  (if  applicable) 

Type  of  travel  activity 
Transportation  Reguest  Number 
Method  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  (nine  digits) 
Responsible  Organization 
Object  Class 
Name  code 

Performing  organization 
Start  date 
End  date 

Primary  Job  Code 

Secondary  Job  Code 

Accounts  Receivable  balance 

Commitment 

Obligation 

Cost 

Disbursement 
Unliquidated  obligation 
Last  activity  information 


Figure  2. 12-23 


- Travel  inquiry  requirements  (concluded) . 


• Open  Travel  Order  Status 

• Open  Travel  Advances 

• Closed  Travel  Order  Status 

• Closed  Travel  Advances 

• Selected  Foreign  Travel 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  Travel  Performance  Section  or  Daily 
Transaction  List  Travel  Advance  Section  reports  described  in 
section  2.19.7. 


2.13  ACCOUNTS  RECEIVABLE  PROCESS 


The  Accounts  Receivable  process  includes  the  recording 
of  establishments,  liquidations,  and  cash  deposits  for 
travel,  commercial,  payroll,  deposit  fund,  and  miscellaneous 
receipt  receivables.  In  addition,  the  process  includes  the 
recording  of  cash  deposits  for  travel  advances,  bad  checks, 
write-offs  of  receivables,  payments  from  the  deposit  fund, 
and  aircraft  spares  activity.  The  various  transactions, 
except  for  aircraft  spares,  are  input  by  the  Fund  Control 
Unit.  Aircraft  spares  transactions  are  input  by  the 
Commercial  Accounts  Unit. 

2.13.1  Update  Requirements 

2.13.1.1  Establishment of accounts  receivable . The 

accounts  receivable  establishment  process  inputs  and  records 
the  establishment  of  all  receivables,  whether  they  are 
travel,  commercial,  payroll,  miscellaneous  receipt,  or 
deposit  fund.  The  establishment  is  normally  recorded  upon 
receipt  of  one  of  the  following  forms: 

• Bill  of  Collection  (Standard  Form  1114B) 

• Voucher  for  Transfers  Between  Appropriations  and/or 
Funds  (Standard  Form  1080) 

• Voucher  and  Schedule  of  Withdrawals  and  Credits 
(Standard  Form  1081) 

• Redemption  of  Unused  Tickets  (Standard  Form  1170) 

• Daily  Fee  Collection  Report  (JSC  Form  53) 

Travel,  commercial,  and  payroll  receivables  may  be 
either  refunds  or  reimbursements.  Refunds  are  normally  for 


such  items  as  overpayments;  the  money  received  is  to  be  used 
to  reduce  the  cost  and  disbursement  (partial  refund)  or  the 
commitment,  obligation,  cost,  and  disbursement  (complete 
refund)  originally  recorded.  Reimbursements  are  payments 
made  by  some  non-NASA  source  on  a reimbursable  order;  the 
money  received  is  not  to  be  used  to  reduce  any  amounts 
originally  recorded.  The  receivable  must  be  identified  as  a 
refund  or  a reimbursement  on  an  establishment.  Whether  a 
refund  is  a partial  refund  or  a complete  refund  must  be 
determined  by  the  system. 

2.13.1.1.1  Establishment  of  accounts  receivable  - 
travel;  The  travel  accounts  receivable  establishment 
process  inputs  and  records  the  establishment  of  a receivable 
that  applies  to  a travel  order.  Travel  receivables  are  for 
such  items  as  unused  airline  tickets,  refunds  of 
overpayments  for  rental  cars,  and  reimbursements  for 
payments  made  on  reimbursable  orders. 

The  travel  accounts  receivable  establishment  process 
consists  of  an  establishment  transaction,  an  update 
transaction,  and  a correction  transaction  defined  as 
follows: 


• Establishment  - a transaction  that  records  the 
establishment  of  the  receivable. 

• Update  - a transaction  that  updates  the 
establishment  of  the  receivable.  The  transaction 
must  have  been  directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  establishment  or 
update  transaction. 


The  input,  processing,  and  output  requirements  for  these 
transactions  are  disucssed  in  the  following  paragraphs. 

iSEEt  ~ Figure  2.13-1  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
travel  accounts  receivable  establishment  process.  Figure 
2.  13-2  defines  the  template  required  for  input  of  these  data 
elements. 

The  establishment  transaction  is  specified  by  the  entry 
of  establishment  dollars;  the  amount  entered  must  be 
positive.  The  update  transaction  is  specified  by  the  update 
indicator  and  the  entry  of  establishment  dollars;  the  amount 
entered  may  be  either  positive  or  negative.  The  correction 
transaction  is  specified  by  the  correction  indicator;  any 
data  elements  that  are  incorrect  may  be  entered.  Only  one 
of  the  three  transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Establishment 

The  establishment  transaction  inputs  and  records  the 
establishment  of  the  receivable.  Each  transaction  must 
update  a travel  performance  record  and  must  create  an 
accounts  receivable  record. 

The  establishment  amount  from  the  template  must  update 
the  establishment  amount  from  the  travel  performance  record. 
The  travel  performance  record  is  defined  by  the  TA  number, 
type  of  travel  activity.  Trip  Number,  and  Transportation 
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Data 

element 

Element 

required 

Source 

Error 

tvne 

Inout/Edit  requirements 

Error 

code 

•As  of’ 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Bill  number 

Yes 

Various 

documents 

Fatal 

Input  for  all  establishment,  update,  and  cor- 
rection transactions.  The  first  six  positions 
must  be  a TA  number;  the  first  position  must  be 
alphabetic,  and  the  remaining  five  must  be  numeric. 
The  last  four  positions  must  be  a type  of  travel 
activity;  the  first  three  positions  must  be 
numeric,  and  the  fourth  must  be  alphabetic.  See 
figure  2.12-2  for  additional  edits. 

C100 

C101 

Trip  number 

Conditional 

Various 

documents 

Fatal 

Input  fpr  establishment,  update,  and  correction 
transactions  when  the  receivable  is  for  a specific 
trip  number  within  a General  Travel  Authorization. 
Must  be  numeric. 

coio 

con 

Transporta- 

tion 

Request 

Humber 

Conditional 

Various 

documents 

Fatal 

Input  for  establishment,  update,  and  correction 
transactions  when  the  receivable  is  for  a trans- 
portation activity  and  there  is  more  than  one 
Transportation  Reguest  Number  for  the  travel 
order-  The  first  position  must  be  alphabetic; 
the  remaining  seven  must  be  numeric.  See 
figure  2,12-2  for  additional  edits. 

C020 

C021 

Establish  ment 
dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  all  establishment  and  update  trans- 
actions and  for  correction  transactions  when  it 
it  is  to  be  corrected.  For  an  establishment 
transaction,  must  be  numeric  and  greater  than  0. 
For  an  update  or  correction  transaction,  must  be 
numeric  and  not  egual  to  0. 

B600 

5601 

B602 

B604 

Date  of  bill 

Conditional 

User  supplied 

Fatal 

Input  for  establishment  transactions  when  the 
date  of  establishment  is  other  than  the  system 
date  and  for  correction  transactions  when  it  is 
to  be  corrected.  Must  be  numeric  and  conform 
to  all  normal  date  edits. 

C110 

Type  of 

receivable: 

travel 

Yes 

User  supplied 

Fatal 

Input  for  all  travel  establishment,  update,  and 
correction  transactions. 

C360 

Name  code 

Conditional 

Various 

documents 

Fatal 

Input  for  all  travel  establishment  transactions 
and  for  correction  transactions  when  it  is  to  be 
corrected.  Must  be  a valid  name  code. 

couo 

C041 

Reimbursement 

Conditional 

User  supplied 

None 

Transaction  modifier  indicating  that  the 
receivable  is  a reimbursement.  Input  only  when 
the  receivable  is  a reimbursement. 

None 

Type  of 

receivable: 

commercial 

Ho 

None 

Fatal 

Must  not  be  input  for  any  Travel  Accounts  Re- 
ceivable Establishment  transaction. 

C361 

riguro  j.13-1.  - Travel  Accounts  receivable*  Establishment  in  nit  anr  eHt  r^quirer-onts. 


Data 

element 

Element 

required 

Source 

Error 

Type  of 

receivable: 

payroll 

No 

None 

Fatal 

Type  of 
receivable: 
miscellaneous 
receipt 

No 

None 

Fatal 

Type  of 
receivable: 
deposit 
fund 

No 

None 

Fatal 

Update 

Optional 

User  supplied 

Fatal 

Correction 

Optional 

User  supplied 

Fatal 

Error 

Inpat/Edit  requirements  code 


Bust  not  be  input  for  any  Travel  Accounts  Re-  C361 

ceivable  Establishment  transaction. 

Bust  not  be  input  for  any  Travel  Accounts  Re-  C361 

ceivable  Establishment  transaction. 

Must  not  be  input  for  any  Travel  Accounts  Re-  C361 

ceivable  Establishment  transaction. 

Transaction  modifier  indicating  that  the  trans-  B062 

action  is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

Transaction  modifier  indicating  that  the  trans-  B062 

action  is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 


S o 

to 

If 

*6 

fcjs 

3S 


Figure  2.13-1.  - Travel  Accounts  Receivable  Establishment  input  and  edit  requirements  (concluded). 


♦♦♦♦IFNS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  Q1  - ESTABLISHMENT  OF  ACCOUNTS  RECEIVABLE 

BILL  NO. - TRIP  NO. TRANS  REQUEST  NO.  

ESTABLISHMENT  $ , , . ± DATE  / / 

TYPE  OF  RECEIVABLE: 

TRAVEL  _ NAME  CODE  REIMBURSEMENT  _ 

COMMERCIAL  _ PURCHASE  REQUEST  NO.  SUFFIX  

DEPOSIT  ON  CONTAINERS  _ REIMBURSEMENT  _ 

PAYROLL  _ MA  PY  OBJECT  CLASS  

PWC  PERF  ORG  REIMBURSEMENT 

MISC  RECEIPT  _ PY  ACCOUNT  SYMBOL  

DEPOSIT  FUND  _ PY  ACCOUNT  SYMBOL  

FOR  CHANGES  ONLY:  UPDATE  CORRECTION 


Figure  2.13-2.  - Establishment  of  Accounts  Receivable  template. 
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Request  Number.  The  TA  number  and  type  of  travel  activity 
are  entered  on  the  template  for  all  travel  receivables;  the 
Trip  Number  is  entered  on  the  template  when  the  receivable 
is  for  a specific  trip  within  a General  Travel 

Authorization.  The  Transportation  Request  Number  is 

generated  by  the  system  when  the  receivable  is  for  a 
transportation  activity  and  there  is  only  one  Transportation 
Request  Number  for  the  travel  order.  It  is  entered  on  the 
template  when  the  receivable  is  for  a transportation 
activity  and  there  is  more  than  one  Transportation  Request 
Number.  For  the  establishment  transaction,  the  record  must 
exist  and  be  open.  The  updated  establishment  amount  must 
not  exceed  the  di sbur semen t . If  the  receiv  able  is  a 
reimbursement,  the  record  must  have  a reimbursable  MA. 

The  accounts  receivable  record  must  be  created  with  the 
following  data  elements: 

• Bill  number  (TA  Number  and  type  of  travel  activity) 

• Date  of  bill 

• Trip  Number 

• Transportation  Request  Number 

• Name  code 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Establishment  Dollar  Amount 

• Reimbursement  indicator  (if  entered) 

• Partial  or  complete  refund  indicator 

All  of  the  data  elements  except  MA,  PY,  FS,  and  the  partial 
or  complete  refund  indicator  are  entered  on  the  template. 


MA#  py,  and  FS  must  be  obtained  by  the  system  from  the 
travel  performance  record;  the  partial  or  complete  refund 
indicator  must  be  generated  as  complete.  The  accounts 
receivable  record  is  defined  by  the  bill  number.  Trip 
Number,  and  Transportation  Request  Number.  For  the 
establishment  transaction,  the  record  must  not  already 
exist. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  travel  performance  and  accounts  receivable  records  must 
exist,  must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  of  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
Amounts  from  the  travel  performance  and  accounts  receivable 
records  must  be  increased  or  reduced.  The  normal  processing 
edits  must  be  satisfied;  in  addition,  a negative  change  must 
not  reduce  any  of  the  amounts  from  either  of  the  records 
below  0.  For  the  travel  accounts  receivable  establishment 
process,  the  only  dollar  data  element  is  establishment 
dollars.  The  processing  requirement  for  the  correction  of 
information  data  elements  specifies  that  the  new  value  of 
the  element  be  overlaid  on  the  old.  The  information  data 
elements  are  the  date  of  bill  and  name  code.  If  any  of  the 
control  data  elements  are  entered  incorrectly,  the 
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transaction  oust  be  reversed  and  a new  transaction  entered. 
The  control  data  elements  are  the  bill  number.  Trip  Number, 
Transportation  Request  Number,  and  the  reimbursement 
indicator. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  travel  accounts 
receivable  establishment  process. 

2.13.1.1.2  Establishment  of  accounts  receivable 
commercial:  The  commercial  accounts  receivable 

establishment  process  inputs  and  records  the  establishment 
of  a receivable  that  applies  to  a contract,  a grant,  a 
contract  or  grant  paid  under  a letter  of  credit,  a T-order, 
a GBL , or  a MILSTRIP/F EDS TRIP  item.  Commercial  receivables 
are  for  such  items  as  overpayments,  refunds  for  deposits  on 
containers,  and  reimbursements  for  payments  made  on 
reimbursable  orders. 

The  commercial  accounts  receivable  establishment 
process  consists  of  an  establishment  transaction,  an  update 
transaction,  and  a correction  transaction  defined  as 
follows: 

• Establishment  - a transaction  that  records  the 
establishment  of  the  receivable. 
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• Update  - a transaction  that  updates  the 
establishment  of  the  receivable.  The  transaction 
must  haVe  been  directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  establishment  or 
update  transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-3  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
commercial  accounts  receivable  establishment  process. 
Figure  2.13-2  defines  the  template  required  for  input  of 
these  data  elements. 

The  establishment  transaction  is  specified  by  the  entry 
of  establishment  dollars;  the  amount  entered  must  be 
positive.  The  update  transaction  is  specified  by  the  update 
indicator  and  the  entry  of  establishment  dollars;  the  amount 
entered  may  be  either  positive  or  negative.  The  correction 
transaction  is  specified  by  the  correction  indicator;  any 
data  elements  that  are  incorrect  may  be  entered.  Only  one 
of  the  three  transactions  may  be  entered  at  any  one  time. 

Processing  **■  The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 
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A 
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Data 

element 

Element 

required 

Source 

Error 

type 

Input/Edit  requirements 

Error 

code 

'As  of' 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
3101 

Bill  number 

Yes 

Various 

documents 

Fatal 

Input  for  all  establishment,  update,  and  correc- 
tion transactions.  Positions  1 through  6 must  be 
numeric.  Positions  7 and  8 must  be  numeric  or  blank. 
Positions  9 and  10  must  be  blank. 

C100 

C101 

Trip  Number 

NO 

None 

Fatal 

Must  not  be  input  for  any  Commercial  Accounts 
Receivable  Establishment  transaction. 

CO  1 2 

Transporta- 

tion 

Request 

Number 

No 

None 

Fatal 

Must  not  be  input  for  any  Commercial  Accounts 
Receivable  Establishment  transaction. 

C022 

Establishment 

dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  all  establishment  and  update  trans- 
actions and  for  correction  transactions  when  it 
is  to  be  corrected.  For  an  establishment 
transaction,  must  be  numeric  and  greater  than  0. 
For  an  update  or  correction  transaction,  must 
be  numeric  and  not  equal  to  0. 

B600 

B601 

B602 

B604 

Date  of 
bill 

Conditional 

Various 

documents 

Fatal 

Input  for  establishment  transactions  when  the 
date  of  establishment  is  other  than  the  system 
date  and  for  correction  transactions  when  it  is 
to  be  corrected.  Must  be  numeric  and  conform 
to  all  normal  date  edits. 

C110 

Type  of 

receivable: 

travel 

No 

None 

Fatal 

Must  not  be  input  for  any  Commercial  Accounts 
Receivable  Establishment  transaction. 

C361 

Type  of 

receivable: 

commercial 

Yes 

User  supplied 

Fatal 

Input  for  all  commercial  establishment,  update, 
and  correction  transactions. 

C360 

Purchase 

Reguest 

Number 

Yes 

Various 

documents 

Fatal 

Input  for  all  commercial  establishement,  update, 
and  correction  transactions.  Positions  1 through 
9 must  be  numeric.  Position  9 must  be  alphabetic 
or  blank. 

B300 

B301 

Suffix 

Conditional 

Various 

documents 

Fatal 

Input  for  commercial  establishment,  update, 
and  correction  transactions  when  other  than  the 

B31 1 

base  Suffix.  Must  be  numeric. 


Figure  2.13-3.  - Commercial  Accounts  Receivable  Establishment  input  and  edit  requirements 
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Data 

element 


Element 

required 


Source 


Error 

t X£e_ 


Error 

code 


In£UiZMAt_reguirements 


KJ 


Deposit  on 
containers 


Reimbursement 


Type  of 

receivable: 

payroll 

Type  of 
receivable: 
miscellaneous 
receipt 

Type  of 
receivable: 
deposit  fund 

Update  ’ 


Correction 


Conditional  User  supplied  Fatal 


Conditional  User  supplied  Fatal 


No  None  Fatal 


No  None  Fatal 


Transaction  modifier  indicating  that  the  re 
ceivable  is  for  a deposit  on  containers.  Input 
only  when  the  receivable  is  for  a deposit  on 
containers.  Hust  not  be  input  when  the 
receivable  is  a reimbursement. 

Transaction  modifier  indicating  that  the  re- 
ceivable is  a reimbursement.  Input  only  when  the 
receivable  is  a reimbursement.  Must  not  be 
input  when  the  receivable  is  for  a deposit  on 
containers. 

Must  not  be  input  for  any  Commercial  Accounts 
Receivable  Establishment  transaction. 


Must  not  be  input  for  any  Commercial  Accounts 
Receivable  Establishment  transaction. 


Ro 


None 


Fatal  Must  not  be  input  for  any  Commercial  Accounts 
Receivable  Establishment  transaction. 


Optional 


Optional 


User  supplied  Fatal 


User  supplied  Fatal 


Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  mis^  not  be  specified. 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 


C370 

C370 

C361 

C361 

C361 
BO  62 

B062 


Figure  2.13-3.  - Commercial  Accounts  Receivable  Establishment  input  and  edit  requirements  (concluded). 


Establishment 

The  establishment  transaction  inputs  and  records  the 
establishment  of  the  receivable.  Each  transaction  must 
create  an  accounts  receivable  record.  If  the  receivable  is 
for  a contract,  grant,  or  contract  or  grant  paid  under  a 
letter  of  credit,  the  transaction  must  update  a contract 
record  and  a performance  record;  if  the  receivable  is  for  a 
T--order,  GBI,  or  MI  LST  RIP/FEDS  TRIP  item,  the  transaction 
must  update  a performance  record. 

If  the  receivable  is  for  a contract,  grant,  or  contract 
or  grant  paid  under  a letter  of  credit,  the  establishment 
amount  from  the  template  must  update  the  establishment 
amount  from  the  contract  record  and  performance  record.  The 
contract  record  is  defined  by  the  Contract/Order  Number 
obtained  from  the  performance  record  and  the  performance 
record  by  the  PR  Number  and  Suffix  entered  on  the  template. 
For  the  establishment  transaction,  both  records  must  exist 
and  be  open. 

For  a contract,  the  updated  establishment  amount  must 
not  exceed  the  disbursement  from  either  the  contract  record 
or  the  performance  record.  If  the  receivable  is  for  a 
deposit  on  containers,  the  updated  establishment  amount  must 
not  exceed  the  deposit  on  containers  from  either  the 
contract  record  or  the  performance  record.  If  the 
receivable  is  a reimbursement,  the  updated  establishment 
amount  must  not  exceed  the  disbursement  for  reimbursable 
orders  from  either  the  contract  record  or  the  performance 
record,  and  the  performance  record  must  have  a reimbursable 
MA.  The  receivable  cannot  be  for  both  a deposit  on 
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containers  and  a reimbursement.  For  a grant,  the  updated 
establishment  amount  must  not  exceed  the  advance  established 
from  either  the  contract  record  or  the  performance  record. 
The  receivable  cannot  be  for  a deposit  on  containers  or  be  a 
reimbursement.  For  a contract  or  grant  paid  under  a letter 
of  credit,  the  updated  establishment  amount  must  not  exceed 
the  withdrawal  from  either  the  contract  record  or  the 
performance  record.  The  receivable  cannot  be  for  a deposit 
on  containers  or  a reimbursement. 

If  the  receivable  is  for  a T-order,  GBL,  or 
MILSTRIP/FEDSTRIP  item,  only  the  performance  record  must  be 
updated.  The  processing  requirements  are  the  same  as  those 
discussed  in  the  preceding  paragraph  for  the  performance 
record.  The  contract  record  for  those  T-orders  for  which 
contract  records  exist  is  not  affected. 


The  accounts  receivable  record  must  be  created  with  the 
following  data  elements. 

• Bill  number 

• Date  of  bill 

• Contract/Order  Number 

• Contractor  name  code 

• purchase  Request  Number  and  Suffix 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Establishment  dollar  amount 

• Reimbursement  indicator  (if  entered) 

• Deposit  on  containers  indicator  (if  entered) 

• Partial  or  complete  refund  indicator 
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All  of  the  data  elements  except  the  Contract/Order  Number, 
contractor  name  code,  MA,  PY,  FS,  and  the  partial  or 
complete  refund  indicator  are  entered  on  the  template.  The 
Contract/Order  Number,  contractor  name  code,  MA,  PY,  and  FS 
must  be  obtained  by  the  system  from  the  performance  record. 
The  partial  or  complete  refund  indicator  must  be  generated 
by  the  system  as  complete  if  the  total  commitment, 
obligation,  cost,  and  disbursement  from  the  performance 
record  are  egual  and  as  partial  if  they  are  not  equal.  The 
accounts  receivable  record  is  defined  by  the  bill  number. 
For  the  establishment  transaction,  the  record  must  not 
already  exist. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  contract,  performance,  and  accounts  receivable  records 
must  exist,  must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollars  data  elements  are  basically  the  same 
as  those  for  the  original  transaction,  except  that  the 
amount  entered  on  the  template  may  be  either  positive  or 
negative.  Amounts  from  the  contract,  performance,  and 
accounts  receivable  records  must  be  increased  or  reduced. 
The  normal  processing  edits  must  be  satisfied;  in  addition, 
a negative  change  must  not  reduce  any  of  the  amounts  from 
any  of  the  records  below  0.  For  the  commercial  accounts 
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receivable  establishment  process,  the  only  dollar  data 
element  is  establishment  dollars.  The  processing 
requirement  for  the  correction  of  information  data  elements 
specifies  that  the  new  value  of  the  element  be  overlaid  on 
the  old.  The  only  information  data  element  is  the  date  of 
bill.  If  any  of  the  control  data  elements  are  entered 
incorrectly,  the  transaction  must  be  reversed  and  a new 
transaction  entered.  The  control  data  elements  are  the  bill 
number,  PE  Number,  Suffix,  the  deposit  on  containers 
indicator,  and  the  reimbursement  indicator. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  commercial 
accounts  receivable  establishment  process. 

2.13.1.1.3  Establishment  of  accounts  receivable  - 
payroll:  The  payroll  accounts  receivable  establishment 
process  inputs  and  records  the  establishment  of  a receivable 
that  applies  to  payroll.  Payroll  receivables  are  for  such 
items  as  employee  overpayments,  jury  duty  pay,  and 
reimbursements  for  payments  made  on  reimbursable  orders. 

The  payroll  accounts  receivable  establishment  process 
consists  of  an  establishment  transaction,  an  update 
transaction,  and  a correction  transaction  defined  as 
follows: 


• Establishment  - a transaction  that  records  the 
establishment  of  the  receivable. 

• Update  - a transaction  that  updates  the 
establishment  of  the  receivable.  The  transaction 
must  have  been  directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  establishment  or 
update  transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-4  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
payroll  accounts  receivable  establishment  process.  Figure 
2. 13-2  defines  the  template  required  for  input  of  these  data 
elements. 

The  establishment  transaction  is  specified  by  the  entry 
of  establishment  dollars;  the  amount  entered  must  be 
positive.  The  update  transaction  is  specified  by  the  update 
indicator  and  the  entry  of  establishment  dollars;  the  amount 
entered  may  be  either  positive  or  negative.  The  correction 
transaction  is  specified  by  the  correction  indicator;  any 
data  elements  that  are  incorrect  may  be  entered.  Only  one 
of  the  three  transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 


Data 

element 


1 As  of* 
Date 


Bill  number 


Trip  Number 


Transporta- 

tion 

Request 

Number 

Establishment 

dollars 


Date  of 
bill 


Type  of 

receivable: 

travel 

Type  of 

receivable: 

commercial 

Ty  pe  of 

receivable: 

payroll 

Method  of 
Authority 


Program  Year 


Element 

required 

Source 

Error 

t 

Tngut/Edit  requirements 

Error 

code 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions* 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired*  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Yes 

Various 

documents 

Fatal 

Input  for  all  establishment,  update,  and  correc- 
tion transactions.  Positions  1 through  6 must  be 
numeric.  Positions  7 and  8 must  be  numeric  or  blank. 
Positions  9 and  10  must  be  blank. 

C100 

C101 

No 

None 

Fatal 

Must  not  be  input  for  any  Payroll  Accounts 
Receivable  Establishment  transaction. 

C0 1 2 

No 

None 

Fatal 

Must  not  be  input  for  any  Payroll  Accounts 
Receivable  Establishment  transaction. 

C022 

Conditional 

Various 

documents 

Fatal 

Input  for  all  establishment  and  update  trans- 
actions and  for  correction  transactions  when  it 
is  to  be  corrected.  For  an  establishment 
transaction,  must  be  numeric  and  greater  than  0. 
For  an  update  or  correction  transaction,  must 
be  numeric  and  not  equal  to  0. 

B600 

B601 

B602 

B604 

Conditional 

Various 

documents 

Fatal 

Input  for  establishment  transactions  when  the 
date  of  establishment  is  other  than  the  system 
date  and  for  correction  transactions  when  it  is 
to  be  corrected.  Must  be  numeric  and  conform 
to  all  normal  date  edits. 

C110 

No 

None 

Fatal 

Must  not  be  input  for  any  Payroll  Accounts 
Receivable  Establishment  transaction. 

C361 

NO 

None 

Fatal 

Must  not  be  input  for  any  Payroll  Accounts 
Receivable  Establishment  transaction. 

C361 

Yes 

User  supplied 

Fatal 

Input  for  all  payroll  establishment,  update,  and 
correction  transactions. 

C360 

Yes 

Various 

documents 

Fatal 

Input  for  all  payroll  establishment,  update, 
and  correction  transactions.  Must  be  a valid 

MA  but  not  97.  Must  be  a reimbursable  MA  if 
the  receivable  is  a reimbursement. 

B110 
Bill 
B 1 1 4 

bus 

Yes 

Various 

documents 

Fatal 

Input  for  payroll  establishment,  update,  and 
correction  transactions  when  PY  is  other  than 
the  current  ^Y.  Must  he  a valid  PY.  Also 
validated  with  FS  and  PWC. 

El  20 
B121 
B 1 26 
C508 
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Data 

element 

Element 

required 

Source 

Error 
1 Ik? 

Inppt/Fdit  requirements 

Error 

code 

object  Class 

Yes 

Various 

documents 

Fatal 

Input  for  all  payroll  establishment,  update,  and 
correction  transactions.  hurt  be  a valid 
object  class. 

B190 

3191 

Primary  Work 
Code 

Conditional 

Various 

documents 

Fatal 

Input  for  all  payroll  establishment,  update,  and 
correction  transactions-  Must  be  nine  digits  and 
a valid  PWC.  Also  validated  with  PY  ana  FS. 

B170 
B 17  1 
B174 
C508 

Performing 

Organization 

Yes 

Various 

documents 

Fatal 

Input,  for  all  payroll  establishment,  update,  and 
correction  transactions.  Bust  be  a valid 
Performing  Organization. 

B320 
B32 1 

Reimbursement 

Conditional 

User  supplied 

None 

Transaction  modifier  indicating  that  the  re- 
ceivable is  a reimbursement.  Input  only  when 
the  receivable  is  a reimbursement. 

C370 

'T'ype  of 
receivable: 
miscellaneous 
receipt 

No 

None 

Fatal 

Bust  not  be  input  for  any  Payroll  Accounts 
Receivable  Establishment  transaction. 

C361 

Type  of 
receivable: 
deposit 
fund 

No 

None 

Fatal 

Must  not  be  input  for  any  Payroll  Accounts 
Receivable  Establishment  transaction. 

C361 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 

B062 

o o 

'}•  i i ■ p.  i 

Figure  2.13-4,  - Payroll  Accounts 


Receivable  Establishment  input  and  edit  requirements  (concluded) . 


The  establishment  transaction  inputs  and  records  the 
establishment  of  the  receivable.  Each  transaction  must 
create  or  update  a payroll  performance  record  and  must 
create  an  accounts  receivable  record.  Payroll  performance 
records  are  specifically  identified  by  MA,  PY,  Object  Class, 
PWC,  and  Performing  organization.  Each  distinct 
combination  of  these  data  elements  was  originally  recorded 
in  a separate  performance  record.  Receivables  related  to 
previously  established  performance  records  must  be  applied 
to  these  records;  for  all  others,  a performance  record  must 
be  created. 

For  the  establishment  transaction,  the  performance 
record  may  or  may  not  exist.  If  the  record  does  not  exist, 
it  must  be  created.  The  establishment  amount  from  the 
template  must  update  the  establishment  amount  from  the 
performance  record.  If  the  receivable  is  being  applied  to  a 
previously  established  performance  record,  the  updated 
establishment  amount  must  not  exceed  the  disbursement.  If 
the  receivable  is  a reimbursement,  the  record  must  have  a 
reimbursable  MA. 

The  performance  record  must  be  created  with  the 
following  data  elements: 

• Contract/Order  Number 

• PR  Number  and  Suffix 

• Method  of  Authority 

• Program  Year 

• Fund  Source 
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• Primary  Work  Code 

• Responsible  Organization 

• Object  Class 

• Performing  Organization 

• Commitment  Dollar  Amount  (equals  0) 

• Obligation  Dollar  Amount  (equals  0) 

• Cost  Dollar  Amount  (equals  0) 

• Disbursement  Dollar  Amount  (equals  0) 

• Establishment  Dollar  Amount 

MA , PY,  Object  Class,  PWC,  and  Performing  Organization  are 
entered  on  the  template;  the  system  must  generate  the 
remaining  elements.  Figure  2. 13-5  contains  a list  of  the 
data  elements  generated  and  their  current  values.  If  the 
MA , PY,  Object  Class,  PWC,  and  Performing  Organization 
combination  is  not  defined  in  the  system,  the  performance 
record  cannot  be  created  or  updated. 

The  accounts  receivable  record  must  be  created  with  the 
following  data  elements; 

• Bill  number 

• Date  of  bill 

• PR  Number  and  Suffix 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Establishment  Dollar  Amount 

• Reimbursement  indicator  (if  entered) 

• Partial  or  complete  refund  indicator 


Data  element 


Value 


Contract/Order  Number 
PE  Number  and  Suffix 
Fund  Source 

Responsible  Organization 


To  be  assigned 
To  be  assigned 
1 

BH 


Figure  2.13-5.  - Payroll  accounts 
receivable  establishment  generated 
data  elements. 


All  of  the  data  elements  except  FS  are  entered  on  the 
template.  FS  must  be  obtained  by  the  system  from  the 
performance  record;  the  partial  or  complete  refund  indicator 
must  be  generated  as  complete.  The  accounts  receivable 
record  is  defined  by  the  bill  number.  For  the  establishment 
transaction,  the  record  must  not  already  exist. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either 'dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  performance  and  accounts  receivable  records  must  exist, 
must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
Amounts  from  the  performance  and  accounts  receivable  records 
must  be  increased  or  reduced.  The  normal  processing  edits 
must  be  satisfied;  in  addition,  a negative  change  must  not 
reduce  any  of  the  amounts  from  either  of  the  records  below 
0.  For  the  payroll  accounts  receivable  establishment 
process,  the  only  dollar  data  element  is  establishment 
dollars.  The  processing  requirement  for  the  correction  of 
information  data  elements  specifies  that  the  new  value  of 
the  element  be  overlaid  on  the  old.  The  only  information 
data  element  is  the  date  of  bill.  If  any  of  the  control 
data  elements  are  entered  incorrectly,  the  transaction  must 
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be  reversed  and  a new  transaction  entered.  The  control  data 
elements  are  the  bill  number,  HA,  PY,  Object  Class,  PWC, 
Performing  Organization,  and  the  reimbursement  indicator. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  payroll 
accounts  receivable  establishment  process. 


2.13.1.1.4  Establishment  of  accounts  receivable 
miscellaneous  receipt:  The  miscellaneous  receipt  accounts 

receivable  establishment  process  inputs  and  records  the 
establishment  of  a receivable  that  applies  to  a general  fund 
miscellaneous  receipt  account.  Figure  2.13-6  contains  a 
list  of  the  various  miscellaneous  receipt  accounts  and  their 
descriptions. 

The  miscellaneous  receipt  accounts  receivable 
establishment  process  consists  of  an  establishment 
transaction,  an  update  transaction,  and  a correction 
transaction  defined  as  follows: 

• Establishment  - a transaction  that  records  the 
establishment  of  the  receivable. 

• Update  - a transaction  that  updates  the 
establishment  of  the  receivable.  The  transaction 
must  have  been  directed  by  written  documentation. 
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ORIGINAL  PAGB 
OF  POOR  QUAli 


liile 


Forfeitures  of  unclaimed  money  and  property 


Fines#  penalties,  and  forfeitures,  not  otherwise 
classified 


Contributions  to  "Conscience  Fund" 

Gifts  to  the  United  states,  not  otherwise  classified 

Interest  on  other  loans  to  individuals  and  private 
organizations 

Sent  of  land 

Rent  of  real  property#  not  otherwise  classified 

Pen*  of  eguipnent  and  other  personal  property 

Sale  of  power  and  Other  utilities,  not  otherwise 
classified 

Sale  of  publications  and  reproductions  not  otherwise 
classified 

Sales  of  miscellaneous  products  and  byproducts, 
not  otherwise  classified 

Fees  and  other  charges  for  accounting  and  auditing 
services 

Service  charges  for  allotments  of  pay  for  savings 
accounts  (P.L.  90-365) 

Fees  and  other  charges  for  other  administrative 
services 

Peer  and  other  services 

Commissions  OR  telephone  pay  stations 

Fees  add  other  charges  for  communication  and 
transportation  services,  not  otherwise  classified 

pusiness  concessions 

Other  fees  and  charges  for  miscellaneous  Services 

Met  proceeds  from  surplus  property  in  the  United 

states 

Proceeds  from  sale  of  eguipoent  and  other  personal 
property,  not  otherwise  classified 

Sale  of  recap  and  salvage  materials 

Recoveries  for  government  property  lost  or  damaged, 
not  otherwise  classified 

Recoveries  under  renegotiation  program 

Miscellaneous  recoveries  of  excess  profits  and  costs 

niscellaneou®  recoveries  and  refunds,  not  otherwise 
classified 


Account 

Symbol 

801060 


Contract/Otder 
Number 


4 * 


To  be  assigned 
801099  To  be  assigned 

801210  To  be  assigned 

801299  To  be  assigned 

301453  To  be  assigned 

801810  To  be  assigned 

801830  To  be  assigned 

601840  To  be  assigned 

802249  To  be  assigned 

802259  To  be  assigned 

BQ2299  To  be  assigned 

802412  To  be  assigned 

802017  To  be  assigned 

802419.1  To  be  assigned 

802419.2  To  be  assigned 

602423  To  be  assigneo 

802429  To  be  assigned 

302465  To  be  assigned 

80249°  To  be  assigned 

802637  To  be  assigned 

302609  To  be  assigned 

«C2653  To  be  assignee 

803014  To  be  assigned 

803031  to  be  assigned 

603032  To  be  assigned 

803099  To  be  assigned 


PR  Number 
ana  Suffix 

KA 

PS 

To 

be 

assigned 

00 

D 

TO 

be 

assigned 

00 

D 

TO 

be 

assigned 

00 

D 

TO 

bs 

assigned 

00 

D 

TO 

be 

assigned 

00 

D 

TO 

be 

assigned 

00 

D 

To 

be 

assigned 

00 

D 

To 

be 

assigned 

00 

D 

To 

be 

assigned 

00 

D 

To 

be 

assigned 

00 

D 

To 

be 

assigned 

00 

0 

To 

be 

assigned 

00 

D 

To 

be 

assigned 

00 

n 

TO 

be 

assigned 

0Q 

0 

TO 

be 

assigned 

00 

0 

TO 

be 

assigned 

00 

0 

TO 

be 

assigned 

00 

0 

TO 

bn 

assigned 

00 

D 

To 

be 

assigned 

00 

0 

To 

be 

assigned 

09 

D 

To 

be 

assigned 

03 

D 

TO 

oe 

assigned 

0° 

C 

TO 

be 

assigned 

00 

c 

To 

be 

assigned 

09 

£ 

TO 

be 

assigned 

00 

o 

To 

be 

assigned 

Oil 

0 

receivable  establishment  generated  data  element?. 


• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  establishment  or 
update  transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-7  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
miscellaneous  receipt  accounts  receivable  establishment 
process.  Figure  2.13-2  defines  the  template  required  for 
input  of  these  data  elements. 

The  establishment  transaction  is  specified  by  the  entry 
of  establishment  dollars;  the  amount  entered  must  be 
positive.  The  update  transaction  is  specified  by  the  update 
indicator  and  the  entry  of  establishment  dollars;  the  amount 
entered  may  be  either  positive  or  negative.  The  correction 
transaction  is  specified  by  the  correction  indicator;  any 
data  elements  that  are  incorrect  may  be  entered.  Only  one 
of  the  three  transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Establishment 

The  establishment  transaction  inputs  and  records  the 
establishment  of  the  receivable.  Each  transaction  must 
create  or  update  a miscellaneous  receipt  performance  record 
and  must  create  an  accounts  receivable  record. 
Miscellaneous  receipt  performance  records  are  specifically 
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Data 

element 

Element 

required 

Source 

Error 

type 

Input/Edit  requirements 

Error 

code 

•As  of1 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
B1Q1 

Bill  number 

Yes 

Various 

documents 

Fatal 

Input  for  all  establishment,  update,  and  correc- 
tion transactions.  Positions  1 through  6 must  be 
numeric.  Positions  7 and  9 must  be  numeric  or  blank. 
Positions  9 and  10  must  be  blank. 

C100 

C101 

Trip  Number 

Ho 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Accounts  Receivable  Establishment  transaction. 

C0 1 2 

Transporta- 

tion 

Request 

Humber 

No 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Accounts  Receivable  Establishment  transaction. 

C022 

Establishment 

dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  all  establishment  and  update  trans- 
actions and  for  correction  transactions  when  it 
is  to  be  corrected.  For  an  establishment 
transaction,  must  be  numeric  and  greater  than  0. 
For  an  update  or  correction  transaction,  must 
be  numeric  and  not  equal  to  0. 

B600 

B601 

B602 

B60U 

Date  of  bill 

Conditional 

Various 

documents 

Fatal 

Input  for  establishment  transactions  when  the 
date  of  establishment  is  other  than  the  system 
date  and  for  correction  transactions  when  it  is 
to  be  corrected.  Must  be  numeric  and  conform 
to  all  normal  date  edits. 

Clio 

Type  of 

receivable: 

travel 

No 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Accounts  Receivable  Establishment  transaction. 

C361 

Type  of 

receivable: 

commercial 

No 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Accounts  Receivable  Establishment  transaction. 

C361 

Type  of 

receivable: 

payroll 

Ho 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Accounts  Receivable  Establishment  transaction. 

C361 

Type  of 
receivable: 
miscellaneous 
receipt 

Yes 

User  supplied 

Fatal 

Input  for  all  miscellaneous  receipt  estab- 
lishment, update,  and  correction  transactions. 

C360 

Program  Year 

Yes 

User  supplied 

Fatal 

Input  for  miscellaneous  receipt  establishment, 
update,  and  correction  transactions  when  PY  is 
other  than  the  current  PY.  Must  be  a valid  PY. 

B120 

B121 

Account 

symbol 

Yes 

Various 

documents 

Fatal 

Input  for  all  miscellaneous  receipt  estab- 
lishment, update,  and  correction  transactions. 
Must  be  a valid  account  symbol. 

C120 
Cl  21 

Figure  2.13-7.  - Miscellaneous  Receipt  Accounts  Receivable  Establishment  input  and  edit  requirements. 


Data 

element 

Type  of 
receivable: 

Element 

required 

No 

Source 

Error 

type 

Inout/Edit  reaui Tenants 

Error 

code 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Accounts  Receivable  Establishment  transactions. 

C361 

deposit 

fund 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the 
transaction  is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 

B062 

transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 


Figure  2.13-7 . 


Miscellaneous  Receipt  Accounts  Receivable  Establishment  input  and  edit  requirements  (concluded) 


identified  by  PY  and  account  symbol.  Each  distinct 
combination  of  PY  and  account  symbol  must  be  recorded  in  a 
separate  performance  record. 

For  the  establishment  transaction,  the  performance 
record  may  or  may  not  exist.  If  the  record  does  not  exist, 
it  must  be  created.  The  establishment  amount  from  the 
template  must  update  the  establishment  amount  from  the 
performance  record. 

The  performance  record  must  be  created  with  the 
following  data  elements: 

• Contract/Order  Number 

• PR  Number  and  Suffix 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Primary  Work  Code  (the  account  symbol) 

• Commitment  Dollar  Amount  (equals  0) 

• Obligation  Dollar  Amount  (equals  0) 

• Cost  Dollar  Amount  (equals  0) 

• Disbursement  Dollar  Amount  (equals  0) 

• Establishment  Dollar  Amount 

PY  and  PWC  are  entered  on  the  template;  the  system  must 
generate  the  remaining  elements.  Figure  2. 13-6  contains  a 
list  of  the  data  elements  generated  and  their  current  values 
for  each  account  symbol.  If  the  PY  and  account  symbol 
combination  is  not  defined  in  the  system,  the  performance 
record  cannot  be  created  or  updated. 
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The  accounts  receivable  record  must  be  created  with  the 
following  data  elements: 

• Bill  number 

• Date  of  bill 

• PR  Number  and  Suffix 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Account  Symbol 

• Establishment  Dollar  Amount 

The  bill  number,  date  of  bill,  PY,  and  account  symbol  are 
entered  on  the  template;  the  remaining  elements  must  be 
obtained  by  the  system  from  the  performance  record.  The 
partial  or  complete  refund  indicator  is  not  applicable  to 
miscellaneous  receipt  receivables.  The  accounts  receivable 
record  is  defined  by  the  bill  number.  For  the  establishment 
transaction,  the  record  must  not  already  exist. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  performance  and  accounts  receivable  records  must  exist, 
must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
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entered  on  the  template  may  be  either  positive  or  negative. 
Amounts  from  the  performance  and  accounts  receivable  records 
must  be  increased  or  reduced.  The  normal  processing  edits 
must  be  satisfied;  in  addition,  a negative  change  must  not 
reduce  any  of  the  amounts  from  either  of  the  records  below 
0.  For  the  miscellaneous  receipt  accounts  receivable 
establishment  process,  the  only  dollar  data  element  is 
establishment  dollars.  The  processing  requirement  for  the 
correction  of  information  data  elements  specifies  that  the 
new  value  of  the  element  be  overlaid  on  the  old.  The  only 
information  data  element  is  the  date  of  bill.  If  any  of  the 
control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  control  data  elements  are  the  bill  number,  PY,  and 
account  symbol. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  miscellaneous 
receipt  accounts  receivable  establishment  process. 

2.13.1.1.5  Establishment  of  accounts  receivable  - 
deposit  fund:  The  deposit  fund  accounts  receivable 
establishment  process  inputs  and  records  the  establishment 
of  a receivable  that  cannot  be  identified  to  a specific 
travel  order,  contract,  grant,  T-order,  GBL, 
MI LSTRI P/FED STRIP  item,  payroll  item,  or  miscellaneous 
receipt  account  and,  thus,  must  be  recorded  in  suspense. 
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When  it  is  identified,  the  receivable  is  transferred. 
Section  2.13.1.7  contains  a discussion  of  the  deposit  fund 
transfer  process. 

The  deposit  fund  accounts  receivable  establishment 
process  consists  of  an  establishment  transaction,  an  update 
transaction,  and  a correction  transaction  defined  as 
follows: 

• Establishment  - a transaction  that  records  the 
establishment  of  the  receivable. 

• Update  - a transaction  that  updates  the 
establishment  of  the  receivable.  The  transaction 
must  have  been  directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  establishment  or 
update  transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-8  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
deposit  fund  accounts  receivable  establishment  process. 
Figure  2.13-2  defines  the  template  required  for  input  of 
these  data  elements. 

The  establishment  transaction  is  specified  by  the  entry 
of  establishment  dollars;  the  amount  entered  must  be 
positive.  The  update  transaction  is  specified  by  the  update 
indicator  and  the  entry  of  establishment  dollars;  the  amount 
entered  may  be  either  positive  or  negative.  The  correction 
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Data 

element 

Element 

required 

Source 

Error 

type. 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Bill  number 

Yes 

Various 

documents 

Fatal 

Trip  Number 

No 

None 

Fatal 

Transporta^ 

tion 

Request 

Humber 

No 

None 

Fatal 

Establishment 

dollars 

Conditional 

Various 

documents 

Fatal 

Date  of  bill 

Conditional 

Various 

documents 

Fatal 

Ty  pe  of 

receivable: 

travel 

No 

Hone 

Fatal 

Type  of 

receivable: 

commercial 

No 

None 

Fatal 

Type  of 

receivable: 

payroll 

No 

None 

Fatal 

Type  of 
receivable: 
miscellaneous 
receipt 

No 

None 

Fatal 

Type  of 
receivable: 
deposit  fund 

Yes 

User  supplied 

Fatal 

Program  Year 

Yes 

User  supplied 

Fatal 

Error 

Inpat/Edit  requirements  code 


Date  providing  for  the  backdating  of  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  8101 

systea  date  is  desired.  When  input,  aust  be  nu- 
aeric  and  conform  to  all  normal  date  edits. 

Input  for  all  establishment,  update,  and  correc-  Cl  00 

tion  transactions.  Positions  1 through  6 aust  be  C101 

numeric.  Positions  7 and  8 must  be  numeric  or  blank. 
Positions  9 and  10  must  be  blank. 

Must  not  be  input  for  any  Deposit  Fund  Accounts  C012 

Receivable  Establishment  transaction. 

Must  not  be  input  for  any  Deposit  Fund  Accounts  C022 

Receivable  Establishment  transaction. 

input  for  all  establishment  and  update  trans-  B600 

actions  and  for  correction  transactions  when  it  B601 

is  to  be  corrected.  For  an  establishment  B602 

transaction,  must  be  numeric  and  greater  than  0-  B604 

For  an  update  or  correction  transaction,  must 
be  numeric  and  not  egual  to  0. 

Input  for  establishment  transactions  when  the  C110 

date  of  establishment  is  other  than  the  systea 
date  and  for  correction  transactions  when  it  is 
to  be  corrected.  Bust  be  numeric  and  conform 
to  all  normal  date  edits. 


Must  not  be  input  for  any  Deposit  Fund  Accounts  C361 

Receivable  Establishment  transaction. 

Must  not  be  input  for  any  Deposit  Fund  Accounts  C361 

Receivable  Establishment  transaction. 

Must  not  be  input  for  any  Deposit  Fund  Accounts  C361 

Receivable  Establishment  transaction. 

Must  not  be  input  for  any  Deposit  Fund  Accounts  C361 

Receivable  Establishment  transaction. 

Input  for  all  deposit  fund  establishment,  update,  C360 

and  correction  transactions. 

Input  for  deposit  fund  establishment,  update,  B120 

and  correction  transactions  when  PY  is  other  B121 

than  the  current  PY.  Must  be  a valid  PY. 


figure  2.13-9.  - Deposit  Fund  Accounts  Receivable  Establishment  input  and  edit  requirements 
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Data 

element 

Account 

symbol 

Update 

Correction 


Element 

required 

Source 

Error 

type 

Input/Edit  requirements 

Error 

code 

Yes 

Various 

documents 

Fatal 

Input  for  deposit  fund  establishment,  update, 
and  correction  transactions  when  other  than 
80X6875-  Hust  be  a valid  account  symbol. 

Cl  20 
Cl  21 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update-  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction-  Input  only  when  the 

B062 

transaction  is  a correction-  Both  the  update 
and  correction  must  not  be  specified. 


rioure  2. 13--.  - Deposit  Fund  Accounts  Receivable  establishment  input  and  edit  requirements  (concluded) 


transaction  is  specified  by  the  correction  indicator;  any 
data  elements  that  are  incorrect  may  be  entered.  Only  one 
of  the  three  transactions  may  be  entered  at  any  one  time. 


The  processing  requirements  are  discussed 


by  transaction  in  the  following  paragraphs. 


Establishment 

The  establishment  transaction  inputs  and  records  the 
establishment  of  the  receivable.  Each  transaction  must 
create  or  update  a deposit  fund  performance  record  and  must 
create  an  accounts  receivable  record.  Deposit  fund 
performance  records  are  specifically  identified  by  PY  and 
account  symbol.  Each  distinct  combination  of  PY  and  account 
symbol  must  be  recorded  in  a separate  performance  record. 

For  the  establishment  transaction,  the  performance 
record  may  or  may  not  exist.  If  the  record  does  not  exist, 
it  must  be  created.  The  establishment  amount  from  the 
template  must  update  the  establishment  amount  from  the 
performance  record. 


The  performance  record  must  be  created  with  the 
following  data  elements: 


• Contract/Order  Number 

• PR  Number  and  Suffix 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Primary  Work  Code  (the  account  symbol) 
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• Commitment  Dollar  Amount  (equals  0) 

• Obligation  Dollar  Amount  (equals  0) 

• Cost  Dollar  Amount  (equals  0) 

• Disbursement  Dollar  Amount  (equals  0) 

• Establishment  Dollar  Amount 

PY  and  PWC  are  entered  on  the  template;  the  system  must 
generate  the  remaining  elements.  Figure  2.13-9  contains  a 
list  of  the  data  elements  generated  and  their  current 
values.  If  the  PY  and  account  symbol  combination  is  not 
defined  in  the  system,  the  performance  record  cannot  be 
created  or  updated. 

The  accounts  receivable  record  must  be  created  with  the 
following  data  elements; 

• Bill  number 

• Date  of  bill 

• PE  Number  and  Suffix 

• Method  of  Authority 

• Program  Year 

• Fund  Source 

• Account  Symbol 

• Establishment  Dollar  Amount 

The  bill  number,  date  of  bill,  PY,  and  account  symbol  are 
entered  on  the  template;  the  remaining  elements  must  be 
obtained  by  the  system  from  the  performance  record.  The 
partial  or  complete  refund  indicator  is  not  applicable  to 
deposit  fund  receivables.  The  accounts  receivable  record  is 
defined  by  the  bill  number.  For  the  establishment 
transaction,  the  record  must  not  already  exist. 
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Data  element 


Value 


Contract/Order  Number 
PE  Number  and  Suffix 
Method  of  Authority 
Fund  Source 


To  be  assigned 
To  be  assigned 


00 

K 


Figure  2.13-9.  - Deposit  Fund  accounts 
receivable  establishment  generated 
data  elements. 


Update  and  Correction 


Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements/  information  data  elements/  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  performance  and  accounts  receivable  records  must  exist, 
must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
Amounts  from  the  performance  and  accounts  receivable  records 
must  be  increased  or  reduced.  The  normal  processing  edits 
must  be  satisfied;  in  addition,  a negative  change  must  not 
reduce  any  of  the  amounts  from  either  of  the  records  below 
0.  For  the  deposit  fund  accounts  receivable  establishment 
process,  the  only  dollar  data  element  is  establishment 
dollars.  The  processing  requirement  for  the  correction  of 
information  data  elements  specifies  that  the  new  value  of 
the  element  be  overlaid  on  the  old.  The  only  information 
data  element  is  the  date  of  bill.  If  any  of  the  control 
data  elements  are  entered  incorrectly,  the  transaction  must 
be  reversed  and  a new  transaction  entered.  The  control  data 
elements  are  the  bill  number,  PY,  and  account  symbol. 

To  satisfy  audit  trail,  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 
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Output  - Section  2.13.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  deposit  fund 
accounts  receivable  establishment  process. 


2.13.1.2  Liquidation of  accounts  receivable . The 

accounts  receivable  liquidation  process  inputs  and  records 
the  liquidation  of  all  receivables,  whether  they  are  travel, 
commercial,  payroll,  miscellaneous  receipt,  or  deposit  fund. 
The  liquidation  is  normally  recorded  upon  receipt  of  one  of 
the  following  forms: 


• Daily  Cash  Receipts  Report  (JSC  Form  168) 

• Voucher  for  Transfers  Between  Appropriations  and/or 
Funds  (Standard  Form  1080) 

• Voucher  and  Schedule  of  Payments  (Standard  Form 

1 166A) 

• Voucher  and  Schedule  of  Withdrawals  and  Credits 

(Standard  Form  1081) 


Receivables  can  be  liquidated  by  either  a cash 
collection  or  a voucher  deduction.  A cash  collection  is  a 
liquidation  by  the  receipt  of  a check  or  cash;  all  cash 
collections  must  be  followed  by  the  deposit  of  the  funds.  A 
voucher  deduction  is  a liquidation  by  an  offset  against  a 
payment;  since  no  funds  are  received,  no  deposit  exists.  A 
receivable  may  be  liquidated  partially  by  a cash  collection 
and  partially  by  a voucher  deduction.  Multiple  cash 
collections  and/or  multiple  voucher  deductions  may  exist. 


The  accounts  receivable  liquidation  process  consists  of 
a cash  collection  transaction,  a voucher  deduction 


a 


transaction,  an  update  transaction,  and  a correction 
transaction  defined  as  follows: 

• Cash  collection  - a transaction  that  records  the 
liquidation  of  the  receivable  by  a cash  collection. 

• voucher  deduction  - a transaction  that  records  the 
liquidation  of  the  receivable  by  a voucher 
deduction. 

• Update  - a transaction  that  updates  the  liquidation 
of  the  receivable.  The  transaction  must  have  been 
directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  the  cash  collection,  voucher 
deduction,  or  update  transaction. 

The  input,  processing,  afed  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 


Ingut  - Figure  2.13-10  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
accounts  receivable  liquidation  process.  Figure  2.13-11 
defines  the  template  required  for  input  of  these  data 
elements. 

The  cash  collection  transaction  is  specified  by  the 
cash  collection  indicator  and  the  entry  of  liquidation 
dollars;  the  amount  entered  must  be  positive.  The  voucher 
deduction  transaction  is  specified  by  the  voucher  deduction 
indicator  and  the  entry  of  liquidation  dollars;  the  amount 
entered  must  be  positive.  The  update  transaction  is 
specified  by  the  update  indicator,  the  cash  collection  or 
voucher  deduction  indicator,  and  the  entry  of  liquidation 
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Data 

element 

Element 

required 

Source 

Error 

type 

Input/Edit  requirements 

Error 

code 

'As  of 
Date 

Optional 

Oser  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B100 
BI0 1 

Bill  number 

Yes 

Various 

documents 

Fatal 

Input  for  all  liquidation,  update,  and  correc- 
tion transactions.  See  figures  2.13-1,  2.13-2, 
2.13-3,  and  2.13-4  for  the  edits. 

C100 

C101 

Trip  Number 

Conditional 

Various 

documents 

Fatal 

Input  for  travel  liquidation,  update,  and 
correction  transactions  when  the  receivable  is 
for  a specific  trip  number  within  a General  Travel 
Authorization.  Nust  be  numeric. 

C010 

C011 

Transporta- 

tion 

Request 

Number 

Conditional 

Various 

documents 

Fatal 

Input  for  travel  liquidation,  update,  and 
correction  transactions  when  the  receivable  is  for  a 
transportation  activity  and  there  is  more  than  one 
Transportation  Request  Number  for  the  travel  order. 
See  figure  2.13-1  for  the  edits. 

C020 

C021 

Liquidation 

dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  all  liquidation  and  update  transactions 
and  for  correction  transactions  when  it  is  to  be 
corrected.  For  a liquidation  transaction,  must 
be  numeric  and  greater  than  0.  For  an  update  or 
correction  transaction,  must  be  numeric  and  not 
equal  to  0. 

B600 

B601 

B602 

B604 

Type  of 

liquidation: 

cash 

collection 

Conditional 

Oser  supplied 

Fatal 

Input  for  all  cash  collection  transactions  ana 
for  update  and  correction  transactions  when  the 
liquidation  is  by  cash  collection. 

B090 

Certificate 
of  deposit 
number 

Conditional 

Various 
documen  £s 

Fatal 

Input  for  all  cash  collection  transactions,  for 
update  transactions  when  the  liquidation  is  by  cash 
collection,  and  for  correction  transactions  when  the 
liquidation  is  by  cash  collection  and  it  is  to 
be  corrected.  Positions  1 and  2 must  be  'CD.* 
Positions  3 and  4 must  be  numeric. 

B940 

B941 

B942 

Type  of 
liquidation: 
voucher 
deduction 

Conditional 

User  supplied 

Fatal 

Input  for  all  voucher  deduction  transactions  and 
for  update  and  correction  transactions  when  the 
liquidation  is  by  voucher  deduction-  Both  the  cash 
collection  and  voucher  deduction  must  not  be 
specified. 

B090 

B091 

Voucher 

number 

Conditional 

Various 

documents 

Fatal 

Input  for  all  voucher  deduction  transactions, 
for  update  transactions  when  the  liquidation  is  by 
voucher  deduction,  and  for  correction  trans- 
actions when  the  liquidation  is  by  voucher  deduction 
and  it  is  to  be  corrected.  Position  1 must  be  J , 
and  positions  2 through  4 must  be  numeric,  or  all 
must  be  numeric. 

B930 

B931 

BS32 

Figure  2.13-10.  - Liquidation  of  Accounts  Receivable  - Cash  Collection  or  Voucher  Oe  lucti -n 

ini>uh  edit  requirements. 


Data 

element 

Element 

required 

Source 

:.rr.or 

type 

Input/Edit  requirements 

Error 

code 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 

B062 

transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 


Figure  2.13-10.  - Liquidation  of  Accounts  Receivable  - Cash  Collection  or  Voucher  Deduction 

input  and  edit  requirements  (concluded) . 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO.  Q2  - LIQUIDATION  OF  ACCOUNTS  RECEIVABLE 

BILL  NO.  - TRIP  NO.  TRANS  REQUEST  NO. 

LIQUIDATION  $ , , . ± 

TYPE  OF  LIQUIDATION:  CASH  COLLECTION  _ CD  NO.  

VOUCHER  DEDUCTION  _ VOUCHER  NO. 
FOR  CHANGES  ONLY:  UPDATE  CORRECTION 


Figure  2.13-11.  - Liquidation  of  Accounts  Receivable  template 
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dollars;  the  amount  entered  may  be  either  positive  or 
negative.  The  correction  transaction  is  specified  by  the 
correction  indicator  and  the  cash  collection  or  voucher 
deduction  indicator;  any  data  elements  that  are  incorrect 
may  be  entered.  Only  one  of  these  four  transactions  may  be 
entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Cash  Collection 

The  cash  collection  transaction  inputs  and  records  the 
liquidation  of  the  receivable  by  a cash  collection.  Each 
transaction  must  update  an  accounts  receivable  record,  a 
performance  record,  and  possibly  a contract  record. 

The  liquidation  amount  from  the  template  must  update 
the  cash  collection  amount  from  the  accounts  receivable 
record.  The  accounts  receivable  record  is  defined  by  the 
bill  number.  Trip  Number,  and  Transportation  Request  Number 
for  travel  receivables  (as  discussed  in  section  2.13.1.1.1 
for  the  travel  performance  record)  and  by  the  bill  number 
for  all  other  receivables.  For  the  cash  collection 
transaction,  the  record  must  exist  and  be  open.  The  updated 
cash  collection  amount  plus  the  voucher  deduction  amount 
must  not  exceed  the  establishment  amount. 

If  the  receivable  is  for  a travel  order,  the 
liquidation  amount  from  the  template  must  update  the  cash 
collection  amount  from  the  travel  performance  record.  The 
travel  performance  record  is  defined  by  the  TA  number,  type 
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of  travel  activity.  Trip  Number,  and  Transportation  Bequest 
Number  obtained  from  the  accounts  receivable  record.  For 
the  cash  collection  transaction,  the  record  must  exist  and 
be  open.  The  updated  cash  collection  amount  plus  the 
voucher  deduction  amount  must  not  exceed  the  establishment 
amount. 

If  the  receivable  is  for  a contract,  grant,  or  contract 
or  grant  paid  under  a letter  of  credit,  the  liquidation 
amount  from  the  template  must  update  the  cash  collection 
amount  from  the  contract  record  and  performance  record.  The 
contract  record  is  defined  by  the  Contract/Order  Number 
obtained  from  the  accounts  receivable  record  and  the 
performance  record  by  the  PB  Number  and  Suffix.  For  the 
cash  collection  transaction,  both  records  must  exist  and  be 
open.  The  updated  cash  collection  amount  plus  the  voucher 
deduction  amount  must  not  exceed  the  establishment  amount 
from  either  the  contract  record  or  the  performance  record. 

If  the  receivable  is  for  a T-order,  GBL,  or 
MILSTBIP/FEDSTBIP  item,  only  the  performance  record  must  be 
updated.  The  processing  requirements  are  the  same  as  those 
discussed  in  the  preceding  paragraph  for  the  performance 
record.  The  contract  record  for  those  T-orders  for  which 
contract  records  exist  is  not  affected. 

If  the  receivable  is  for  a payroll  item,  a 
miscellaneous  receipt  account,  or  a deposit  fund,  only  the 
performance  record  must  be  updated.  The  performance  record 
is  defined  by  the  PB  Number  and  Suffix  obtained  from  the 
accounts  receivable  record.  The  processing  requirements  are 
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the  same  as  those  discussed  in  the  preceding  paragraphs  for 
performance  records. 

In  addition,  the  CD  number  from  the  template  must  be 
added  to  both  the  accounts  receivable  record  and  the 
performance  record.  In  the  case  of  multiple  partial 
liquidations,  only  the  CD  number  of  the  last  transaction 
affecting  the  records  must  be  maintained. 

Voucher  Deduction 

The  voucher  deduction  transaction  inputs  and  records 
the  liquidation  of  a receivable  by  a voucher  deduction. 
Each  transaction  must  update  an  accounts  receivable  record, 
a performance  record,  and  possibly  a contract  record. 

The  processing  requirements  for  the  voucher  deduction 
transaction  correspond  to  those  for  the  cash  collection 
transaction;  the  only  difference  specifies  that  the  amount 
updated  is  the  voucher  deduction  amount  instead  of  the  cash 
collection  amount.  In  addition,  the  voucher  number  from  the 
template  must  be  added  to  both  the  accounts  receivable 
record  and  the  performance  record.  In  the  case  of  multiple 
partial  liquidations,  only  the  voucher  number  of  the  last 
transaction  affecting  the  records  must  be  maintained. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions. 
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the  performance,  contract,  and  accounts  receivable  records 
must  exist,  must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
Amounts  from  the  contract,  performance,  and  accounts 
receivable  records  must  be  increased  or  reduced.  The  normal 
processing  edits  must  be  satisfied;  in  addition,  a negative 
change  must  not  reduce  any  of  the  amounts  from  any  of  the 
records  below  0.  For  the  accounts  receivable  liquidation 
process,  the  only  dollar  data  element  is  liquidation 
dollars.  The  processing  requirement  for  the  correction  of 
information  data  elements  specifies  that  the  new  value  of 
the  element  be  overlaid  on  the  old.  The  information  data 
elements  are  the  CD  number  and  voucher  number.  If  any  of 
the  control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  control  data  elements  are  the  bill  number.  Trip  Number, 
and  Transportation  Request  Number. 

In  addition,  for  the  update  transaction,  the  CD  number 
or  voucher  number  from  the  template  must  be  added  to  both 
the  accounts  receivable  record  and  the  performance  record. 
Only  the  CD  number  or  voucher  number  of  the  last  transaction 
affecting  the  records  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 
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Output  - Section  2.13.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  accounts 
receivable  liquidation  process. 

2.13.1.3  Certificate  of  deposit  - accounts  receivable . 
The  accounts  receivable  certificate  of  deposit  process 
inputs  and  records  the  deposit  of  cash  received  to  liquidate 
all  receivables,  whether  they  are  travel,  commercial, 
payroll,  miscellaneous  receipt,  or  deposit  fund.  The 
deposit  is  normally  recorded  upon  receipt  of  a Certificate 
of  Deposit  (Standard  Form  219)  using  information  from  the 
Daily  Cash  Receipts  Report  (Standard  Form  168) . 

2.13.1.3.1  Certificate  of  deposit  - travel:  The 

travel  certificate  of  deposit  process  inputs  and  records  the 
deposit  of  cash  received  to  liquidate  a travel  receivable. 

The  travel  certificate  of  deposit  process  consists  of  a 
deposit  transaction,  an  update  transaction,  and  a correction 
transaction  defined  as  follows: 

• Deposit  - a transaction  that  records  the  deposit. 

• Update  - a transaction  that  updates  the  deposit. 
The  transaction  must  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  deposit  or  update 
transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 
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Input  - Figure  2.13-12  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  lust  be  performed  for  the 
travel  certificate  of  deposit  process.  Figure  2.13-13 
defines  the  template  reguired  for  input  of  these  data 
elements. 

The  deposit  transaction  is  specified  by  the  entry  of  CD 
dollars;  the  amount  entered  must  be  positive.  The  update 
transaction  is  specified  by  the  update  indicator  and  the 
entry  of  CD  dollars;  the  amount  entered  may  be  either 
positive  or  negative.  The  correction  transaction  is 
specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Deposit 

The  deposit  transaction  inputs  and  records  the  deposit. 
Each  transaction  must  update  an  accounts  receivable  record 
and  a travel  performance  record.  If  the  receivable  is  a 
refund,  the  transaction  must  update  a PWA  account.  The  CD 
amount  from  the  template  must  be  input  as  a positive  amount 
but  must  be  given  a negative  sign  for  processing. 

The  CD  amount  from  the  template  must  update  the  CD 
amount  from  the  accounts  receivable  record.  The  accounts 
receivable  record  is  defined  by  the  bi.il  number.  Trip 
Number,  and  Transportation  Request  Number  (as  described  in 
section  2.13.1.1.1  for  the  travel  performance  record).  For 
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Data 

element 

Element 

required 

Source 

Error 

type. 

•As  of* 
Da  te 

Optional 

User  supplied 

Fatal 

Bill  number 

Yes 

Form  168 

Fatal 

Trip  Number 

Conditional 

Form  168 

Fatal 

Transporta- 

tion 

Request 

Number 

Conditional 

Form  168 

Fatal 

Certificate 
of  deposit 
dollars 

Conditional 

Form  168 

Fatal 

Certificate 
of  deposit 
number 

Conditional 

Form  168 

Fatal 

Update 

Optional 

User  supplied 

Fatal 

Correction 

Optional 

User  supplied 

Fatal 

Ingut^Edlt  requirements 


Date  providing  for  the  backdating  of  transactions* 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

Input  for  all  deposit,  update,  and  correction 
transactions.  The  first  six  positions  must  be 
a TA  Number;  the  first  position  must  be  alphbetic, 
and  the  remaining  five  must  be  numeric.  The  last 
four  positions  must  be  a type  of  travel  activity; 
the  first  three  positions  must  be  numeric,  and 
the  fourth  must  be  alphabetic.  See  figure 
2.12-2  for  additional  edits. 

Input  for  deposit,  update,  and  correction  trans- 
actions when  the  receivable  is  for  a specific 
trip  number  within  a General  Travel  Authorization. 
Bust  be  numeric. 

Input  for  deposit,  update,  and  correction  trans- 
actions when  the  receivable  is  for  a transportation 
activity  and  there  is  more  than  one  Transportation 
Request  Number  for  the  travel  order.  The  first  posi- 
tion must  be  alphabetic,  and  the  remaining  seven  must 
be  numeric.  See  figure  2.12-2  for  additional  edits. 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to  be 
corrected.  For  a deposit  transaction,  must  be 
numeric  and  greater  than  0.  For  an  update  or 
correction  transaction,  oust  be  nuaeric  and  not 
equal  to  0. 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to 
be  corrected.  positions  1 and  2 must  be  *CD. 1 
Positions  3 and  4 must  be  numeric. 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 


Error 

code 


B 1 00 
B 1 0 1 


C100 

C101 


C010 

C011 


C020 

C021 


B600 

B601 

B602 

B604 


B940 

B941 


B062 


B062 


Figure  2*13-12.  - Travel  Certificate  of  Deposit  input  and  edit  requirements. 


****IFMS  SEPTEHBER  30,  1974  AS  OF  / / 

★♦♦♦TEMPLATE  NO.  Q3  - CERTIFICATE  OF  DEPOSIT 

BILL  NO. - TRIE  NO. TRANS  REQUEST  NO. 

CD  $ , , . ± CD  NO. 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


Figure  2.13-13.  - Certificate  of  Deposit  template. 


the  deposit  transaction,  the  record  must  exist  and  be  open. 
The  updated  CD  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 

The  CD  amount  from  the  template  must  also  update  the  CD 
amount  from  the  travel  performance  record.  The  travel 
performance  record  is  defined  by  the  TA  Number,  type  of 
travel  activity.  Trip  Number,  and  Transportation  Request 
Number  obtained  from  the  accounts  receivable  record.  For 
the  deposit  transaction,  the  record  must  exist  and  be  open. 
The  updated  C.D  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 

If  the  receivable  is  a refund,  the  CD  amount  from  the 
template  must  reduce  the  commitment,  obligation,  cost,  and 
disbursement  from  the  travel  performance  record.  None  of 
these  amounts  may  be  reduced  below  0.  The  funds  must  be 
returned  to  the  PWA  account  indicated  by  the  accounting 
information  of  the  performance  record.  The  issues  of  the 
PWA  account  must  be  sufficient.  Whether  the  receivable  is  a 
refund  must  be  determined  by  the  system  from  the  partial  or 
complete  refund  indicator  from  the  accounts  receivable 
record. 

In  addition,  the  CD  number  from  the  template  must  be 
added  to  both  the  accounts  receivable  record  and  the  travel 
performance  record.  Only  the  CD  number  of  the  last 
transaction  affecting  the  records  must  be  maintained. 


Update  and  Correction 


Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  travel  performance  and  accounts  receivable  records  must 
exist,  must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
The  amount  entered  must  be  given  a reversed  sign,  and 
amounts  from  the  travel  performance  and  accounts  receivable 
records  must  be  increased  or  reduced.  Funds  must  be 
returned  to  or  obtained  from  the  PWA  accounts.  The  normal 
processing  edits  must  be  satisfied;  in  addition,  a negative 
change  must  not  increase  any  of  the  CD  amounts  from  any  of 
the  records  above  0.  For  the  travel  certificate  of  deposit 
process,  the  only  dollar  data  element  is  CD  dollars.  The 
processing  requirement  for  the  correction  of  information 
data  elements  specifies  that  the  new  value  of  the  element  be 
overlaid  on  the  old.  The  only  information  data  element  is 
the  CD  number.  If  any  of  the  control  data  elements  are 
entered  incorrectly,  the  transaction  must  be  reversed  and  a 
new  transaction  entered.  The  control  data  elements  are  the 
bill  number.  Trip  Number,  and  Transportation  Bequest  Number. 

In  addition,  for  the  update  transaction,  the  CD  number 
from  the  template  must  be  added  to  both  the  accounts 
receivable  record  and  the  travel  performance  record.  Only 
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the  CD  number  of  the  last  transaction  affecting  the  records 
must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  travel 
certificate  of  deposit  process. 

2.13.1.3.2  Certificate  of  deposit  - commercial:  The 

commercial  certificate  of  deposit  process  inputs  and  records 
the  deposit  of  cash  received  to  liquidate  a commercial 
receivable. 

The  commercial  certificate  of  deposit  process  consists 
of  a deposit  transaction,  an  update  transaction,  and  a 
correction  transaction  defined  as  follows: 

• Deposit  - a transaction  that  records  the  deposit. 

• Update  - a transaction  that  updates  the  deposit. 
The  transaction  must  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  deposit  or  update 
transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 


Input  - Figure  2.  13-14  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
commercial  certificate  of  deposit  process.  Figure  2.13-13 
defines  the  template  required  for  input  of  these  data 
elements. 

The  deposit  transaction  is  specified  by  the  entry  of  CD 
dollars;  the  amount  entered  must  be  positive.  The  update 
transaction  is  specified  by  the  update  indicator  and  the 
entry  of  CD  dollars;  the  amount  entered  may  be  either 
positive  or  negative.  The  correction  transaction  is 
specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Deposit 

The  deposit  transaction  inputs  and  records  the  deposit. 
Each  transaction  must  update  an  accounts  receivable  record. 
If  the  receivable  is  for  a contract,  grant,  or  contract  or 
grant  paid  under  a letter  of  credit,  the  transaction  must 
update  a contract  record,  a performance  record,  and,  if 
necessary,  letter  of  credit  records;  if  the  receivable  is 
for  a T-order,  GBL,  or  MI LSTRI P/FEDS TRIP  item,  the 
transaction  must  update  a performance  record.  If  the 
receivable  is  a refund,  the  transaction  may  update  a PWA 
account.  The  CD  amount  from  the  template  must  be  input  as  a 
positive  amount  but  must  be  given  a negative  sign  for 
processing. 
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Data 

element 

Element 

required 

Source 

'As  of' 
Date 

Optional 

User 

supplied 

Bill  number 

Yes 

Form 

168 

Trip  Number 

No 

None 

Transporta- 

tion 

Reguest 

Number 

No 

None 

Certificate 
of  deposit 
dollars 

Conditional 

Form 

168 

Certificate 
of  deposit 
number 

Conditional 

Form 

168 

Update 

Optional 

User 

supplied 

Correction 

Optional 

User 

supplied 
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Comnerc 
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Error  Error 

type  Ipput/Edit  requirements  code 

Fatal  Date  providing  for  the  backdating  of  transactions.  B100 

Inpv.  ; only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

Fatal  Input  for  all  deposit,  update,  and  correction  Cl 00 

transactions.  Positions  1 through  6 must  be  Cl 01 

numeric.  Positions  7 and  8 must  be  numeric  or  blank. 

Positions  9 and  TO  must  be  blank. 

Fatal  Must  not  be  input  for  any  Commercial  Certificate  C0 12 

of  Deposit  transaction. 

Fatal  dust  not  be  input  for  any  Commercial  Certificate  C022 

of  Deposit  transaction. 


Fatal  Input  for  all  deposit  and  update  transactions  B600 

and  for  correction  transactions  when  it  is  to  B601 

be  corrected.  For  a deposit  transaction,  must  B602 

be  numeric  and  greater  than  0.  For  an  update  B604 

or  correction  transaction,  must  be  numeric  and 
not  egual  to  0. 

Fatal  Input  for  all  deposit  and  update  transactions  B940 

and  for  correction  transactions  when  it  is  to  B941 

be  corrected.  Positions  1 and  2 must  be  •CD.1 
Positions  3 and  4 must  be  numeric. 

Fatal  Transaction  modifier  indicating  that  the  trans-  B062 


action  is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

Fatal  Transaction  modifier  indicating  that  the  trans-  B062 

action  is  a correction.  Input  only  when  the 
transaction  is  a correction-  Both  the  update 
and  correction  must  not  be  specified. 


Certificate  of  Deposit  input  and  edit  requirements. 


,,  v The  CD  amount  from  the  template  must  update  the  CD 
amount  from  the  accounts  receivable  record.  The  accounts 

V5,  y 

receivable  record  is  defined  by  the  bill  number.  For  the 
deposit  transaction,  the  record  must  exist  and  be  open.  The 
updated  CD  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 

If  the  receivable  is  for  a contract,  grant,  or  contract 
or  grant  paid  under  a letter  of  credit,  the  CD  amount  from 
the  template  must  update  the  CD  amount  from  the  contract 
record  and  performance  record.  The  contract  record  is 
defined  by  the  Contract/Order  Number  obtained  from  the 
accounts  receivable  record  and  the  performance  record  by  the 
PR  Number  and  Suffix.  For  the  deposit  transaction,  both 
records  must  exist  and  be  open.  The  updated  CD  amount, 
without  the  negative  sign,  must  not  exceed  the  cash 
collection  amount  from  either  the  contract  record  or  the 
performance  record. 

For  a contract,  the  CD  amount  from  the  template  must 
reduce  the  cost  and  disbursement  from  the  contract  record 
and  performance  record  if  the  receivable  is  a partial 
refund.  If  the  receivable  is  a complete  refund,  the  CD 
amount  must  reduce  the  obligation,  cost,  and  disbursement 
from  the  contract  record  and  the  commitment,  obligation, 
cost,  and  disbursement  from  the  performance  record.  If  the 
receivable  is  for  a deposit  on  containers,  the  CD  amount 
must  reduce  the  deposit  on  containers.  None  of  these 
amounts  may  be  reduced  below  0.  If  the  commitment  is 
reduced,  the  funds  must  be  returned  to  the  PWA  account 
indicated  by  the  accounting  information  of  the  performance 
record.  The  issues  of  the  PWA  account  must  be  sufficient. 
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Whether  the  receivable  is  a partial  refund  or  a complete 
refund  oust  be  determined  by  the  system  from  the  partial  or 
complete  refund  indicator  from  the  accounts  receivable 
record.  Whether  the  receivable  is  for  a deposit  on 
containers  must  be  determined  by  the  system  from  the  deposit 
on  containers  indicator  from  the  accounts  receivable  record. 

For  a grant,  the  CD  amount  from  the  template  must 
reduce  the  cost,  disbursement,  advance  established,  and 
advance  liquidated  from  the  contract  record  and  performance 
record  if  the  receivable  is  a partial  refund.  If  the 
receivable  is  a complete  refund,  the  CD  amount  must  reduce 
the  obligation,  cost,  disbursement,  advance  established,  and 
advance  liquidated  from  the  contract  record  and  the 
commitment,  obligation,  cost,  disbursement,  advance 
established,  and  advance  liquidated  from  the  performance 
record.  None  of  these  amounts  may  be  reduced  below  0.  If 
the  commitment  is  reduced,  the  funds  must  be  returned  to  the 
appropriate  PWA  account.  The  issues  of  the  PWA  account  must 
be  sufficient. 

For  a contract  or  a grant  paid  under  a letter  of 
credit,  the  CD  amount  from  the  template  must  reduce  the 
cost,  disbursement,  and  withdrawal  from  the  contract  record 
and  performance  record,  the  withdrawal  from  the  letter  of 
credit  withdrawal  record,  and  the  disbursement  from  the 
letter  of  credit  control  record  if  the  receivable  is  a 
partial  refund.  If  the  receivable  is  a complete  refund,  the 
CD  amount  must  reduce  the  obligation,  cost,  disbursement, 
issuance,  and  withdrawal  from  the  contract  record;  the 
commitment,  obligation,  cost,  disbursement,  issuance,  and 
withdrawal  from  the  performance  record;  the  issuance  from 


the  letter  of  credit  issuance  record;  the  withdrawal  from 
the  letter  of  credit  withdrawal  record;  and  the  issuance, 
withdrawal,  and  disbursement  from  the  letter  of  credit 
control  record.  None  of  these  amounts  may  be  reduced  below 
0.  If  the  commitment  is  reduced,  the  funds  must  be  returned 
to  the  appropriate  PWA  account.  The  issues  of  the  PWA 
account  must  be  sufficient. 

If  the  receivable  is  for  a T^order,  GBL,  or 
MILSTBIP/FEDSTRIP  item,  only  the  performance  record  must 
normally  be  updated.  The  processing  requirements  are  the 
same  as  those  discussed  in  the  preceding  paragraphs  for  the 
performance  record.  For  those  T-orders  for  which  contract 
records  exist,  the  cost  must  be  reduced  when  the  cost  from 
the  performance  record  is  reduced. 

In  addition,  the  CD  number  from  the  template  must  be 
added  to  both  the  accounts  receivable  record  and  the 
performance  record.  Only  the  CD  number  of  the  last 
transaction  affecting  the  records  must  be  maintained. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  contract,  performance,  and  accounts  receivable  records 
must  exist,  must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
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those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
The  amount  entered  must  be  given  a reversed  sign,  and 
amounts  from  the  contract,  performance,  accounts  receivable, 
and  letter  of  credit  records  must  be  increased  or  reduced. 
Funds  must  be  returned  to  or  obtained  from  the  PWA  accounts. 
The  normal  processing  edits  must  be  satisfied;  in  addition, 
a negative  change  must  not  increase  any  of  the  CD  amounts 
from  any  of  the  records  above  0.  For  the  commercial 
certificate  of  deposit  process,  the  only  dollar  data  element 
is  CD  dollars.  The  processing  requirement  for  the 
correction  of  information  data  elements  specifies  that  the 
new  value  of  the  element  be  overlaid  on  the  old.  The  only 
information  data  element  is  the  CD  number.  If  any  of  the 
control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  only  control  data  element  is  the  bill  number. 

In  addition,  for  the  update  transaction,  the  CD  number 
from  the  template  must  be  added  to  both  the  accounts 
receivable  record  and  the  performance  record.  Only  the  CD 
number  of  the  last  transaction  affecting  the  records  must  be 
maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  commercial 
certificate  of  deposit  process. 
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2.13.1.3.3  Certificate  of  deposit  - payroll:  The 

payroll  certificate  of  deposit  process  inputs  and  records 
the  deposit  of  cash  received  to  liquidate  a payroll 
receivable. 

The  payroll  certificate  of  deposit  process  consists  of 
a deposit  transaction,  an  update  transaction,  and  a 
correction  transaction  defined  as  follows: 

• Deposit  - a transaction  that  records  the  deposit. 

• Update  - a transaction  that  updates  the  deposit. 
The  transaction  oust  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  deposit  or  update 
transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-15  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
payroll  certificate  of  deposit  process.  Figure  2.13-13 
defines  the  template  required  for  input  of  these  data 

elements. 

The  deposit  transaction  is  specified  by  the  entry  of  CD 
dollars;  the  amount  entered  must  be  positive.  The  update 

transaction  is  specified  by  the  update  indicator  and  the 

entry  of  CD  dollars;  the  amount  entered  may  be  either 

positive  or  negative.  The  correction  transaction  is 
specified  by  the  correction  indicator;  any  data  elements 

2.13-61 


Q 2 

gS 

§6 


M 

U) 

I 

cn 

ro 


Data 

element 

Element 

required 

Source 

Error 

Input/Edit  requirements 

Error 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions  - 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B100 
B 10  1 

Bill  number 

Yes 

Form  219 

Fatal 

Input  for  all  deposit,  update,  and  correction 
transactions.  Positions  1 through  6 must  be 
numeric.  Positions  7 and  8 must  be  numeric  or 
blank.  Positions  9 and  10  must  be  blank. 

C100 

C101 

Trip  Number 

No 

None 

Fatal 

Must  Kot  be  input  for  any  Payroll  Certificate  of 
Deposit  transaction. 

C012 

Transporta- 

tion 

Request 

Number 

No 

None 

Fatal 

Must  not  be  input  for  any  Payroll  Certificate  of 
Deposit  transaction. 

C022 

Certificate 
of  deposit 
dollars 

Conditional 

Porm  168 

Fatal 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to 
be  corrected.  For  a deposit  transaction,  must 
be  numeric  and  greater  than  0.  For  an  update 
or  correction  transaction,  must  be  numeric  and 
not  equal  to  0. 

B600 

B601 

B602 

B604 

Certificate 
of  deposit 
number 

Conditional 

Form  168 

Fatal 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to 
be  corrected.  Positions  1 and  2 must  be  *CD.# 
Positions  3 and  4 must  be  numeric. 

B940 

B941 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 

B062 

Fiqurc  2.13-15.  - Payroll  Certificate  of  Deposit  input  and  edit  requirements . 


that  are  incorrect  may  be  entered.  Only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Deposit 

The  deposit  transaction  inputs  and  records  the  deposit. 
Each  transaction  must  update  an  accounts  receivable  record 
and  a payroll  performance  record.  If  the  receivable  is  a 
refund,  the  transaction  must  update  a PWA  account.  The  CD 
amount  from  the  template  must  be  input  as  a positive  amount 
but  must  be  given  a negative  sign  for  processing. 

The  CD  amount  from  the  template  must  update  the  CD 
amount  from  the  accounts  receivable  record.  The  accounts 
receivable  record  is  defined  by  the  bill  number.  For  the 
deposit  transaction,  the  record  must  exist  and  be  open.  The 
updated  CD  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 

The  CD  amount  from  the  template  must  also  update  the  CD 
amount  from  the  payroll  performance  record.  The  payroll 
performance  record  is  defined  by  the  PR  Number  and  Suffix 
obtained  from  the  accounts  receivable  record.  For  the 
deposit  transaction,  the  record  must  exist  and  be  open.  The 
updated  CD  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 

If  the  receivable  is  a refund,  the  CD  amount  from  the 
template  must  reduce  the  commitment,  obligation,  cost,  and 
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disbursement  from  the  payroll  perfornance  record.  None  of 
these  aaoants  may  be  reduced  belov  0.  The  funds  nust  be 
returned  to  the  PWA  account  indicated  by  the  accounting 
information  of  the  perfornance  record.  The  issues  of  the 
PWA  account  must  be  sufficient.  Whether  the  receivable  is  a 
refund  must  be  determined  by  the  system  from  the  partial  or 
complete  refund  indicator  from  the  accounts  receivable 
record. 

In  addition,  the  CD  number  from  the  template  must  be 
added  to  both  the  accounts  receivable  record  and  the  payroll 
performance  record.  Only  the  CD  number  of  the  last 
transaction  affecting  the  records  nust  be  maintained. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  payroll  performance  and  accounts  receivable  records  must 
exist,  nust  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
The  amount  entered  must  be  given  a reversed  sign,  and 
amounts  from  the  payroll  performance  and  accounts  receivable 
records  must  be  increased  or  reduced.  Funds  must  be 
returned  to  or  obtained  from  the  PWA  accounts.  The  normal 
processing  edits  must  be  satisfied;  in  addition,  a negative 
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change  must  not  increase  any  of  the  CD  amounts  from  any  of 
the  records  above  0.  Por  the  payroll  certificate  of  deposit 
process,  the  only  dollar  data  element  is  CD  dollars.  The 
processing  reguirement  for  the  correction  of  information 
data  elements  specifies  that  the  new  value  of  the  element  be 
overlaid  on  the  old.  The  only  information  data  element  is 
the  CD  number.  If  any  of  the  control  data  elements  are 
entered  incorrectly,  the  transaction  must  be  reversed  and  a 
new  transaction  entered.  The  only  control  data  element  is 
the  bill  number. 

In  addition,  for  the  update  transaction,  the  CD  number 
from  the  template  must  be  added  to  both  the  accounts 
receivable  record  and  the  payroll  performance  record.  Only 
the  CD  number  of  the  last  transaction  affecting  the  records 
must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  payroll 
certificate  of  deposit  process. 

2.13.1.3.4  Certificate  of  deposit  - miscellaneous 
receipt:  The  miscellaneous  receipt  certificate  of  deposit 
process  inputs  and  records  the  deposit  of  cash  received  to 
liquidate  a miscellaneous  receipt  receivable. 


The  miscellaneous  receipt  certificate  of  deposit 

process  consists  of  a deposit  transaction,  an  update 

transaction,  and  a correction  transaction  defined  as 
follows: 

• Deposit  - a transaction  that  records  the  deposit. 

• Update  - a transaction  that  updates  the  deposit. 
The  transaction  must  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  deposit  or  update 
transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-16  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
miscellaneous  receipt  certificate  of  deposit  process. 
Figure  2.13-13  defines  the  template  required  for  input  of 
these  data  elements. 

The  deposit  transaction  is  specified  by  the  entry  of  CD 
dollars;  the  amount  entered  must  be  positive.  The  update 

transaction  is  specified  by  the  update  indicator  and  the 

entry  of  CD  dollars;  the  amount  entered  may  be  either 

positive  or  negative.  The  correction  transaction  is 

specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 


Data 

element 


Element 

required 


Error 


Input/Edit  requirements 


Error 

code 


•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Bill  number 

Yes 

Form  168 

Fatal 

Input  for  all  deposit,  update,  and  correction 
transactions.  Positions  1 through  6 must  be 
numeric.  Positions  7 and  8 must  be  numeric  or  blank. 
Positions  9 and  10  must  be  blank. 

C100 

C101 

Trip  Number 

No 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Certificate  of  Deposit  transaction. 

C012 

Transporta- 

tion 

Reguest 

Number 

No 

None 

Fatal 

Must  not  be  input  for  any  Miscellaneous  Receipt 
Certificate  of  Deposit  transaction. 

C022 

Certificate 
of  deposit 
dollars 

Conditional 

Form  168 

Fatal 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to 
be  corrected.  For  a deposit  transaction,  must 
be  numeric  and  greater  than  0.  For  an  update 
or  correction  transaction,  must  be  numeric  and 
not  equal  to  0. 

B600 

B601 

B602 

B604 

Certificate 
of  deposit 
number 

Conditional 

Form  168 

Fatal 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to 
be  corrected.  Positions  1 and  2 must  be  *CD. * 
Positions  3 and  4 must  be  numeric. 

B940 

B941 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Co rrection 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 

B062 

transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 
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Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Deposit 

The  deposit  transaction  inputs  and  records  the  deposit. 
Each  transaction  must  update  an  accounts  receivable  record 
and  a miscellaneous  receipt  performance  record.  The  CD 
amount  from  the  template  must  be  input  as  a positive  amount 
but  must  be  given  a negative  sign  for  processing. 

The  CD  amount  from  the  template  must  update  -the  CD 
amount  from  the  accounts  receivable  record.  The  accounts 
receivable  record  is  defined  by  the  bill  number.  For  the 
deposit  transaction,  the  record  must  exist  and  be  open.  The 
updated  CD  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 

The  CD  amount  from  the  template  must  also  update  the  CD 
amount  from  the  miscellaneous  receipt  performance  record. 
The  miscellaneous  receipt  performance  record  is  defined  by 
the  PE  Number  and  Suffix  obtained  from  the  accounts 
receivable  record.  For  the  deposit  transaction,  the  record 
must  exist  and  be  open.  The  updated  CD  amount,  without  the 
negative  sign,  must  not  exceed  the  cash  collection  amount. 

In  addition,  the  CD  number  from  the  template  must  be 
added  to  both  the  accounts  receivable  record  and  the 
miscellaneous  receipt  performance  record.  Only  the  CD 
number  of  the  last  transaction  affecting  the  records  must  be 
maintained. 


Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements*  For  both  the  update  and  correction  transactions, 
the  miscellaneous  receipt  performance  and  accounts 
receivable  records  must  exist,  must  be  open,  and  must  be 
changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
The  amount  entered  must  be  given  a reversed  sign,  and 
amounts  from  the  miscellaneous  receipt  performance  and 
accounts  receivable  records  must  be  increased  or  reduced. 
The  normal  processing  edits  must  be  satisfied;  in  addition, 
a negative  change  must  not  increase  any  of  the  CD  amounts 
from  either  of  the  records  above  0.  For  the  miscellaneous 
receipt  certificate  of  deposit  process,  the  only  dollar  data 
element  is  CD  dollars.  The  processing  requirement  for  the 
correction  of  information  data  elements  specifies  that  the 
new  value  of  the  element  be  overlaid  on  the  old.  The  only 
information  data  element  is  the  CD  number.  If  any  of  the 
control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  only  control  data  element  is  the  bill  number. 

In  addition,  for  the  update  transaction,  the  CD  number 
from  the  template  must  be  added  to  both  the  accounts 
receivable  record  and  the  miscellaneous  receipt  performance 
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record.  Only  the  CD  number  of  the  last  transaction 
affecting  the  records  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  miscellaneous 
receipt  certificate  of  deposit  process. 


2.13.1.3.5  Certificate  of  deposit  - deposit  fund:  The 

deposit  fund  certificate  of  deposit  process  inputs  and 
records  the  deposit  of  cash  received  to  liquidate  a deposit 
fund  receivable. 

The  deposit  fund  certificate  of  deposit  process 
consists  of  a deposit  transaction,  an  update  transaction, 

i-  . 

and  a correction  transaction  defined  as  follows: 


• Deposit  - a transaction  that  records  the  deposit. 

• Update  - a transaction  that  updates  the  deposit. 
The  transaction  must  have  been  directed  by  written 
documentation. 

• Correction  — a transaction  that  corrects  any  data 
elements  entered  in  either  the  deposit  or  update 
transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 
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Input  - Figure  2.13-17  contains  a list  of  data  eleients 
that  must  be  input  and  edits  that  must  be  performed  for  the 
deposit  fund  certificate  of  deposit  process.  Figure  2.13-13 
defines  the  template  required  for  input  of  these  data 
elements. 

The  deposit  transaction  is  specified  by  the  entry  of  CD 
dollars;  the  amount  entered  must  be  positive.  The  update 
transaction  is  specified  by  the  update  indicator  and  the 
entry  of  CD  dollars;  the  amount  entered  may  be  either 
positive  or  negative.  The  correction  transaction  is 
specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Deposit 

The  deposit  transaction  inputs  and  records  the  deposit. 
Each  transaction  must  update  an  accounts  receivable  record 
and  a deposit  fund  performance  record.  The  CD  amount  from 
the  template  must  be  input  as  a positive  amount  but  must  be 
given  a negative  sign  for  processing. 

The  CD  amount  from  the  template  must  update  the  CD 
amount  from  the  accounts  receivable  record.  The  accounts 
receivable  record  is  defined  by  the  bill  number.  For  the 
deposit  transaction,  the  record  must  exist  and  be  open.  The 
updated  CD  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 
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Data 

element 


Element 

required 


Source 


Input/Edit  requirements 


Error 

code 


NJ 


Error 

£IESl_ 


•AS  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Bill  number 

Yes 

Form  168 

Fatal 

Input  for  all  deposit,  update,  and  correction 
transactions.  Positions  1 through  6 must  be 
numeric.  Postions  7 and  8 must  be  numeric  or  blank. 
Positions  9 and  10  must  be  blank. 

C100 

C101 

Trip  Number 

No 

None 

Fatal 

Bust  not  be  input  for  any  Deposit  Fund  Certifi- 
cate of  Deposit  transaction. 

C0 1 2 

Transporta- 

tion 

Reguest 

Number 

No 

None 

Fatal 

Must  not  be  input  for  any  Deposit  Fund  Certifi- 
cate of  Deposit  transaction. 

C022 

Certificate 
of  deposit 
dollars 

Conditional 

Form  168 

Fatal 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to 
be  corrected.  For  a deposit  transaction,  must 
be  numeric  and  greater  than  0.  For  an  update 
or  correction  transaction,  must  be  numeric  and 
not  egual  to  0. 

B600 

B601 

B602 

B604 

Certificate 
of  deposit 
number 

Conditional 

Form  168 

Fatal 

Input  for  all  deposit  and  update  transactions 
and  for  correction  transactions  when  it  is  to 
be  corrected.  Positions  1 and  2 must  be  *CD. 1 
Positions  3 and  4 must  be  numeric. 

B940 
B 94 1 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 

B 062 

and  correction  must  not  be  specified. 


\ 

! 


Figure  2.13-17.  - Deposit  Fund  Certificate  of  Deposit  input  and  edit  requirements. 


The  CD  amount  from  the  template  must  also  update  the  CD 
amount  from  the  deposit  fund  performance  record.  The 
deposit  fund  performance  record  is  defined  by  the  PR  Number 
and  Suffix  obtained  from  the  accounts  receivable  record. 
For  the  deposit  transaction,  the  record  must  exist  and  be 
open.  The  updated  CD  amount,  without  the  negative  sign, 
must  not  exceed  the  cash  collection  amount. 

In  addition,  the  CD  number  from  the  template  must  be 
added  to  both  the  accounts  receivable  record  and  the  deposit 
fund  performance  record.  Only  the  CD  number  of  the  last 
transaction  affecting  the  records  must  be  maintained. 

Update  and  Correction 

Updates  are  made. to  dollar  data  elements;  corrections 
are  made  to  either  dollar  data  elements,  information  data 
elements,  or  control  data  elements.  For  both  the  update  and 
correction  transactions,  the  deposit  fund  performance  and 
accounts  receivable  records  must  exist,  must  be  open,  and 
must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
The  amount  entered  must  be  given  a reversed  sign,  and 
amounts  from  the  deposit  fund  performance  and  accounts 
receivable  records  must  be  increased  or  reduced.  The  normal 
processing  edits  must  be  satisfied;  in  addition,  a negative 
change  must  not  increase  any  of  the  CD  amounts  from  either 
of  the  records  above  0.  For  the  deposit  fund  certificate  of 


deposit  process,  the  only  dollar  data  element  is  CD  dollars. 
The  processing  requirement  for  the  correction  of  information 
data  elements  specifies  that  the  new  value  of  the  element  be 
overlaid  on  the  old.  The  only  information  data  element  is 
the  CD  number.  If  any  of  the  control  data  elements  are 
entered  incorrectly,  the  transaction  must  be  reversed  and  a 
new  transaction  entered.  The  only  control  data  element  is 
the  bill  number. 

In  addition,  for  the  update  transaction,  the  CD  number 
from  the  template  must  be  added  to  both  the  accounts 
receivable  record  and  the  deposit  fund  performance  record. 
Only  the  CD  number  of  the  last  transaction  affecting  the 
records  must  be  maintained. 

To  satisfy  audit,  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  deposit  fund 
certificate  of  deposit  process. 

2.13.1.4  Certificate  of  deposit  - travel  advance.  The 
travel  advance  certificate  of  deposit  process  inputs  and 
records  the  deposit  of  cash  received  to  liquidate  a travel 
advance.  The  deposit  is  normally  recorded  upon  receipt  of  a 
Certificate  of  Deposit  (Standard  Form  219).  Unlike  the 
accounts  receivable,  the  deposit  of  travel  advances  is 
recorded  in  total  for  the  CD  number  and  not  for  each 
individual  travel  advance. 
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^ ' The  travel  advance  certificate  of  deposit  process 

* * consists  of  a deposit  transaction,  an  update  transaction, 

and  a correction  transaction  defined  as  follows: 

• Deposit  - a transaction  that  records  the  deposit. 

• Update  - a transaction  that  updates  the  deposit. 
The  transaction  oust  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  deposit  or  update 
transaction. 

The  input,  processing,  and  output  reguirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  — Figure  2. 13-18  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
x ^ tranvel  advance  certificate  of  deposit  process.  Figure 

2. 13-19  defines  the  template  required  for  input  of  these 
data  elements. 


The  deposit  transaction  is  specified  by  the  entry  of  CD 
dollars;  the  amount  entered  must  be  positive.  The  update 

1 transaction  is  specified  by  the  update  indicator  and  the 

entry  of  CD  dollars;  the  amount  entered  may  be  either 

positive  or  negative.  The  correction  transaction  is 

specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered,  only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 

Processing  — The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 


Data 

Element 

Error 

Error 

element 

required 

Source 

User  supplied 

t £££_ 
Fatal, 

Input/Edit  requirements 

code 

1 As  of* 
Date 

Optional 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B100 

B101 

Certificate 
of  deposit 
number 

Yes 

Form  219 

Patal 

Input  for  all  deposit,  update,  and  correction  trans- 
actions. Positions  1 and  2 must  be  ’CD*.  Positions 
3 and  4 must  be  numeric. 

B940 

B941 

certificate 
of  deposit 
dollars 

Yes 

Form  219 

Fatal 

Input  for  all  deposit,  update,  and  correction 
transactions.  For  a deposit  on  transaction,  must 
be  numeric  and  greater  than  0.  For  an  update 
or  correction  transaction,  must  be  numeric  and 
not  equal  to  0. 

B600 

B601 

B602 

B604 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 

B062 

Figure  2.13-18.  - Travel  Advance  Certificate  of  Deposit  input  and  edit  requirements. 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  MO.  Q4  - TRAVEL  ADVANCE  CERTIFICATE  OF  DEPOSIT 

CD  NO. CD  $ , . ± 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


Figure  2.13-19.  - Travel  Advance  Certificate  of 

Deposit  template. 


Deposit 


The  deposit  transaction  inputs  and  records  the  deposit. 
Each  transaction  must  update  a travel  advance  control 
record.  The  CD  amount  from  the  template  must  be  input  as  a 
positive  amount  but  must  be  given  a negative  sign  for 
processing. 

The  CD  amount  from  the  template  must  update  the  CD 
amount  from  the  travel  advance  control  record.  The  travel 
advance  control  record  is  defined  by  the  CD  number.  For  the 
deposit  transaction,  the  record  must  exist  and  be  open.  The 
updated  CD  amount,  without  the  negative  sign,  must  not 
exceed  the  cash  collection  amount. 


Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements  or  control  data  elements.  For  both  the  update 
and  correction  transactions,  the  travel  advance  control 
record  must  exist,  must  be  open,  and  must  be  changed 
appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
The  amount  entered  must  be  given  a reversed  sign,  and  the 
amount  from  the  travel  advance  control  record  must  be 
increased  or  reduced.  The  normal  processing  edits  must  be 
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satisfied;  in  addition , a negative  change  Bust  not  increase 
the  amount  above  0.  For  the  travel  advance  certificate  of 
deposit  process,  the  only  dollar  data  element  is  CD  dollars. 
If  the  control  data  elenent  is  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  only  control  data  elenent  is  the  CD  number. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  travel  advance 
certificate  of  deposit  process. 

2.13.1.5  Bad  check  or write-off.  The  bad  check  or 

write-off  process  inputs  and  records  either  a bad  check  or 
the  write-off  of  an  uncollectible  receivable.  The  bad  check 
is  normally  recorded  upon  receipt  of  a debit  memo  stating 
that  the  check  cannot  be  honored  because  of  insufficient 
funds.  The  write-off  is  recorded  upon  receipt  of  any 
document  indicating  that  the  receivable  is  uncollectible. 

The  bad  check  or  write-off  process  consists  of  a bad 
check  transaction,  a write-off  transaction,  an  update 
transaction,  and  a correction  transaction  defined  as 
follows: 


• Bad  check  - a transaction  that  records  the  bad  check 
and  the  reversal  of  the  original  cash  collection  and 
deposit. 
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• Write-off  - a transaction  that  records  the  write- 
off. 

• Update  - a transaction  that  updates  the  bad  check  or 
the  write-off.  The  transaction  must  have  been 
directed  by  written  documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  the  bad  check,  write-off,  or 
update  transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2. 13-20  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
bad  check  or  write-off  process.  Figure  2.13-21  defines  the 
template  required  for  input  of  these  data  elements. 

The  bad  check  transaction  is  specified  by  the  bad  check 
indicator  and  the  entry  of  the  dollar  amount;  the  amount 
entered  must  be  positive.  The  write-off  transaction  is 
specified  by  the  write-off  indicator  and  the  entry  of  the 
dollar  amount;  the  amount  entered  must  be  positive.  The 
update  transaction  is  specified  by  the  update  indicator,  the 
bad  check  or  write-off  indicator,  and  the  entry  of  the 
dollar  amount;  the  amount  entered  may  be  either  positive  or 
negative.  The  correction  transaction  is  specified  by  the 
correction  indicator  and  the  bad  check  or  write-off 
indicator;  any  data  elements  that  are  incorrect  may  be 
entered.  Only  one  of  the  four  transactions  may  be  entered 
at  any  one  time. 
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ORIGINAL  PAGB  IS 
OP  POOR  QUALITY 


’ -A 


Data 

element 

Element 

required 

Source 

Error 

t 

Tnpnt/Edit  requirements 

Error 

code 

•As  of* 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
B101 

Bill  number 

Yes 

Various 

documents 

Fatal 

Input  for  all  bad  check,  write-off,  update,  and 
correction  transactions.  For  a travel  receivable, 
the  first  six  positions  must  be  a TA  number;  the 
first  position  must  be  alphabetic,  and  the  re- 
maining five  must  be  numeric.  The  last  four 
positions  must  be  a type  of  travel  activity;  the 
first  three  positions  must  be  numeric,  and  the 
fourth  must  be  alphabetic.  See  figure  2.12-2  for 
additional  edits.  For  all  other  receivables, 
positions  1 through  6 must  be  numeric.  Positions 
7 and  8 must  be  numeric  or  blank.  Positions  9 and 
10  must  be  blank. 

C100 

C101 

Trip  Number 

Conditional 

Various 

documents 

Fatal 

Input  for  travel  bad'  check,  write-off,  update, 
and  correction  transactions  when  the  receivable 
is  for  a specific  trip  number  within  a General 
Travel  Authorization.  Must  be  numeric. 

C010 

C011 

Transporta- 

tion 

Reguest 

Number 

Conditional 

Various 

documents 

Fatal 

Input  for  travel  bad  check,  write-off,  update, 
and  correction  transactions  when  the  receivable 
is  for  a transportation  activity  and  there  is 
more  than  one  Transportation  Request  Number  for 
the  travel  order.  The  first  position  must  be 
alphabetic;  the  remaining  seven  must  be  numeric. 
See  figure  2.12-2  for  additional  edits. 

C020 

C021 

Dollar 

Amount 

Conditional 

Various 

documents 

Fatal 

Input  for  all  bad  check,  write-off,  and  update 
transactions  and  for  correction  transactions 
when  it  is  to  be  corrected.  For  a bad  check  or 
write-off  transaction,  must  be  numeric  and 
greater  than  0.  For  an  update  or  correction 
transaction,  must  be  numeric  and  not  equal  to  0. 

B600 

B601 

B602 

BS04 

Type  of 

transaction: 

bad 

check 

Conditional 

User  supplied 

Fatal 

Input  for  all  bad  check  transactions  and  for 
update  and  correction  transactions  when  there 
is  a bad  check.  Both  the  bad  check  and  write- 
off must  not  be  specified. 

B010 

3011 

Certificate 
of  deposit 
number 

Conditional 

Various 

documents 

Fatal 

Input  for  all  bad  check  transactions,  for  update 
transactions  when  there  is  a bad  check,  and  for 
correction  transactions  when  there  is  a bad 
check  and  it  is  to  be  corrected.  Positions  1 

B940 

B941 

B942 

and  2 oust  be  ‘CD.*  Positions  3 and  4 oust  be 
numeric. 


Figure  2.13-20.  - Bad  Check  or  Write-Off  input  and  edit  requirements. 


Data 

element 

Element 

required 

Source 

Error 

Voucher  Number 

Conditonal 

User  supplied 

Fatal 

Type  of 

Conditional 

User  supplied 

Fatal 

transaction: 

write-off 

Update 

Optional 

User  supplied 

Fatal 

Correction 

Optional 

User  supplied 

Fatal 

Input/Edit  requirements 


Input  for  all  bad  check  transactions,  for  update 
transactions  when  there  is  a bad  check,  and  for 
correction  transactions  when  there  is  a bad  check 
and  it  is  to  be  corrected.  Position  1 must  be  J 
ana  positions  2 through  4 tiust  be  numeric,  or  all 
must  be  numeric- 

input  for  all  write-off  transactions  and  for 
update  and  correction  transactions  when  there 
is  a write-off.  Both  the  bad  check  and  write- 
off must  not  be  specified. 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 


Error 

code 


B930 

B931 

B932 


B010 
B0 1 1 


B062 


B062 


Figure  2. 13-20. 


- 3ad  Check  or  Write-Off  input  and  edit  requirements  (concluded)  . 


****IFMS  SEPTEMBER  30,  1974  AS  OP  / / 

♦♦♦♦TEMPLATE  NO.  Q5  - BAD  CHECK  OH  WRITE-OFF 

BILL  NO. - TRIP  NO.  TRANS  REQUEST  NO. 

AMOUNT  $ , , . ± 

TYPE  OF  TRANSACTION:  BAD  CHECK  _ CD  NO.  VOUCHER  NO 

WRITE-OFF 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION 


Figure  2.13-21.  - Bad  Check  or  Write-Off  template 


Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 

Bad  Check 


The  bad  check  transaction  inputs  and  records  a bad 
check  and  the  reversal  of  the  original  cash  collection  and 
deposit.  Each  transaction  must  update  an  accounts 
receivable  record,  a performance  record,  and  possibly  a 
contract  record  and  letter  of  credit  records.  If  the 
receivable  is  a refund,  the  transaction  may  update  a PWA 
account.  The  processing  to  record  the  reversal  of  the 
original  cash  collection  and  deposit  is  the  opposite  of  the 
original  processing. 

The  bad  check  amount  from  the  template  must  update  the 
bad  check  amount  from  the  accounts  receivable  record,  must 
reduce  the  cash  collection  amount,  and  must  increase  the  CD 
amount.  The  accounts  receivable  record  is  defined  by  the 
bill  number.  Trip  Number,  and  Transportation  Request  Number 
for  travel  receivables  (as  discussed  in  section  2.13.1.1.1 
for  the  travel  performance  record)  and  by  the  bill  number 
for  all  other  receivables.  For  the  bad  check  transaction, 
the  record  must  exist  and  be  open.  The  cash  collection 
amount  must  not  be  reduced  below  0,  and  the  CD  amount  must 
not  be  increased  above  0. 

If  the  receivable  is  for  a travel  order,  the  bad  check 
amount  from  the  template  must  update  the  bad  check  amount 
from  the  travel  performance  record,  must  reduce  the  cash 
collection  amount,  and  must  increase  the  CD  amount.  The 
travel  performance  record  is  defined  by  the  TA  Number,  type 
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of  travel  activity.  Trip  Number,  and  Transportation  Request 
Number  obtained  from  the  accounts  receivable  record.  For 
the  bad  check  transaction,  the  record  must  exist  and  be 
open.  The  cash  collection  amount  must  not  be  reduced  below 
0,  and  the  CD  amount  must  not  be  increased  above  0.  If  the 
receivable  is  a refund,  the  bad  check  amount  must  increase 
the  commitment,  obligation,  cost,  and  disbursement.  The 
funds  must  be  obtained  from  the  PWA  account  indicated  by  the 
accounting  information  of  the  performance  record.  The 
balance  of  the  PWA  account  must  be  sufficient.  Whether  the 
receivable  is  a refund  must  be  determined  by  the  system  from 
the  partial  or  complete  refund  indicator  from  the  accounts 
receivable  record. 

If  the  receivable  is  for  a contract,  grant,  or  contract 
or  grant  paid  under  a letter  of  credit,  the  bad  check  amount 
from  the  template  must  update  the  bad  check  amount  from  the 
contract  record  and  performance  record,  must  reduce  the  cash  v 

collection  amount,  and  must  increase  the  CD  amount.  The 
contract  record  is  defined  by  the  Contract/Order  Number 
obtained  from  the  accounts  receivable  record  and  the 
performance  record  by  the  PR  Number  and  Suffix.  For  the  bad 
check  transaction,  both  records  must  exist  and  be  open.  The 
cash  collection  amount  must  not  be  reduced  below  0,  and  the 
CD  amount  must  not  be  increased  above  0. 

For  a contract,  the  bad  check  amount  from  the  template 
must  increase  the  cost  and  disbursement  from  the  contract 
record  and  performance  record  if  the  receivable  is  a partial 
refund.  If  the  receivable  is  a complete  refund,  the  bad 
check  amount  must  increase  the  obligation,  cost,  and 
disbursement  from  the  contract  record  and  the  commitment. 
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obligation,  cost,  and  disbursement  fron  the  performance 
record.  If  the  receivable  is  for  a deposit  on  containers, 
the  bad  check  amount  must  increase  the  deposit  on 
containers.  If  the  commitment  is  increased,  the  funds  must 
be  obtained  from  the  appropriate  PW A account.  The  balance 
of  the  PWA  account  must  be  sufficient.  Whether  the 
receivable  is  a partial  refund  or  a complete  refund  must  be 
determined  by  the  system  from  the  partial  or  complete  refund 
indicator  from  the  accounts  receivable  record.  Whether  the 
receivable  is  for  a deposit  on  containers  must  be  determined 
by  the  system  from  the  deposit  on  containers  indicator  from 
the  accounts  receivable  record. 

For  a grant,  the  bad  check  amount  from  the  template 
must  increase  the  cost,  disbursement,  advance  established, 
and  advance  liquidated  from  the  contract  record  and 
performance  record  if  the  receivable  is  a partial  refund. 
If  the  receivable  is  a complete  refund,  the  bad  check  amount 
must  increase  the  obligation,  cost,  disbursement,  advance 
established,  and  advance  liquidated  from  the  contract  record 
and  the  commitment,  obligation,  cost,  disbursement,  advance 
established,  and  advance  liquidated  from  the  performance 
record.  If  the  commitment  is  increased,  the  funds  must  be 
obtained  from  the  appropriate  PWA  account.  The  balance  of 
the  PWA  account  must  be  sufficient. 

For  a contract  or  grant  paid  under  a letter  of  credit, 
the  bad  check  amount  from  the  template  must  increase  the 
cost,  disbursement,  and  withdrawal  from  the  contract  record 
and  performance  record,  the  withdrawal  from  the  letter  of 
credit  withdrawal  record,  and  the  disbursement  from  the 
letter  of  credit  control  record  if  the  receivable  is  a 
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partial  refund.  If  the  receivable  is  a complete  refund,  the 
bad  check  amount  must  increase  the  obligation,  cost, 
disbursement,  issuance,  and  withdrawal  from  the  contract 
record;  the  commitment,  obligation,  cost,  disbursement, 
issuance,  and  withdrawal  from  the  performance  record;  the 
issuance  from  the  letter  of  credit  issuance  record;  the 
withdrawal  from  the  letter  of  credit  withdrawal  record;  and 
the  issuance,  withdrawal,  and  disbursement  from  the  letter 
of  credit  control  record.  If  the  commitment  is  increased, 
the  funds  must  be  obtained  from  the  appropriate  PWA  account. 
The  balance  of  the  PWA  account  must  be  sufficient. 

If  the  receivable  is  for  a T-order,  GBL,  or 
MILSTRIP/FEDSTRIP  item,  only  the  performance  record  must 
normally  be  updated.  The  processing  requirements  are  the 
same  as  those  discussed  in  the  preceding  paragraphs  for  the 
performance  record.  For  those  T— orders  for  which  contract 
records  exist,  the  cost  must  be  increased  when  the  cost  from 
the  performance  record  is  increased. 

If  the  receivable  is  for  a payroll  item,  the  bad  check 
amount  from  the  template  must  update  the  bad  check  amount 
from  the  payroll  performance  record,  must  reduce  the  cash 
collection  amount,  and  must  increase  the  CD  amount.  The 
payroll  performance  record  is  defined  by  the  PR  Number  and 
Suffix  obtained  from  the  accounts  receivable  record.  For 
the  bad  check  transaction,  the  record  must  exist  and  be 
open.  The  cash  collection  amount  must  not  be  reduced  below 
0,  and  the  CD  amount  must  not  be  increased  above  0.  If  the 
receivable  is  a refund,  the  bad  check  amount  must  increase 
the  commitment,  obligation,  cost,  and  disbursement.  The 
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funds  must  be  obtained  from  the  appropriate  PWA  account. 
The  balance  of  the  PWA  account  must  be  sufficient. 

If  the  receivable  is  for  a miscellaneous  receipt 
account  or  a deposit  fund,  the  bad  check  amount  from  the 
template  must  update  the  bad  check  amount  from  the 
miscellaneous  receipt  performance  record  or  the  deposit  fund 
performance  record,  must  reduce  the  cash  collection  amount, 
and  must  increase  the  CD  amount.  The  performance  record  is 
defined  by  the  PR  Number  and  Suffix  obtained  from  the 
accounts  receivable  record.  For  the  bad  check  transaction, 
the  record  must  exist  and  be  open.  The  cash  collection 
amount  must  not  be  reduced  below  0,  and  the  CD  amount  must 
not  be  increased  above  0. 

In  addition,  the  CD  number  and  voucher  number  from  the 
template  must  be  added  to  both  the  accounts  receivable 
record  and  the  performance  record.  Only  the  CD  number  and 
voucher  number  of  the  last  transaction  affecting  the  records 
must  be  maintained. 


Write-Off 

The  write-off  transaction  inputs  and  records  the  write- 
off of  a receivable.  Each  transaction  must  update  an 
accounts  receivable  record,  a performance  record,  and 
possibly  a contract  record.  & write-off  is  a form  of 

liquidation,  and  the  processing  to  record  the  write-off 
corresponds  closely  to  that  of  the  liquidation. 

The  write-off  amount  from  the  template  must  update  the 
write-off  amount  from  the  accounts  receivable  record.  The 
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accounts  receivable  record  is  defined  by  the  bill  number. 
Trip  Number,  and  Transportation  Request  Number  for  travel 
receivables  (as  discussed  in  section  2.13.1.1.1  for  the 
travel  performance  record)  and  by  the  bill  number  for  all 
other  receivables.  For  the  write-off  transaction,  the 
record  must  exist  and  be  open.  The  updated  write-off  amount 
plus  the  cash  collection  amount  plus  the  voucher  deduction 
amount  must  not  exceed  the  establishment  amount. 

If  the  receivable  is  for  a travel  order,  the  write-off 
amount  from  the  template  must  update  the  write-off  amount 
from  the  travel  performance  record.  The  travel  performance 
record  is  defined  by  the  TA  Number,  type  of  travel  activity. 
Trip  Number,  and  Transportation  Request  Number  obtained  from 
the  accounts  receivable  record.  For  the  write-off 
transaction,  the  record  must  exist  and  be  open.  The  updated 
write-off  amount  plus  the  cash  collection  amount  plus  the 
voucher  deduction  amount  must  not  exceed  the  establishment 
amount. 

If  the  receivable  is  for  a contract,  grant,  or  contract 
or  grant  paid  under  a letter  of  credit,  the  write-off  amount 
from  the  template  must  update  the  write-off  amount  from  the 
contract  record  and  performance  record.  The  contract  record 
is  defined  by  the  Contract/Order  Number  obtained  from  the 
accounts  receivable  record  and  the  performance  record  by  the 
PR  Number  and  Suffix.  For  the  write-off  transaction,  both 
records  must  exist  and  be  open.  The  updated  write-off 
amount  plus  the  cash  collection  amount  plus  the  voucher 
amount  must  not  exceed  the  establishment  amount  from  either 
the  contract  record  or  the  performance  record. 
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or 


If  the  receivable  is  for  a T-order,  GBL, 

MILSTRIP/FEDSTRIP  item,  only  the  performance  record  must  be 
updated.  The  processing  reguireaents  are  the  same  as  those 
discussed  in  the  preceding  paragraph  for  the  performance 
record.  The  contract  record  for  those  T-orders  for  which 
contract  records  exist  is  not  affected. 

If  the  receivable  is  for  a payroll  item,  a 

miscellaneous  receipt  account,  or  a deposit  fund,  only  the 
performance  record  must  be  updated.  The  performance  record 
is  defined  by  the  PR  Number  and  Suffix  obtained  from  the 
accounts  receivable  record.  The  processing  requirements  are 
the  same  as  those  discussed  in  the  preceding  paragraphs  for 
performance  records. 

Update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  performance,  contract,  and  accounts  receivable  records 
must  exist,  must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  that  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
Amounts  from  the  contract,  performance,  and  accounts 
receivable  records  must  be  increased  or  reduced.  The  normal 
processing  edits  must  be  satisfied;  in  addition,  a negative 
change  must  not  reduce  any  of  the  amounts  from  any  of  the 


records  below  0.  For  the  bad  Chech  or  write-off  process, 
the  only  dollar  data  element  is  the  dollar  amount.  The 
processing  requirement  for  the  correction  of  information 
data  elements  specifies  that  the  new  value  of  the  element  be 
overlaid  on  the  old.  The  information  data  elements  are  the 
CD  number  and  voucher  number  for  a bad  check.  If  any  of  the 
control  data  elements  are  entered  incorrectly,  the 
transaction  must  be  reversed  and  a new  transaction  entered. 
The  control  data  elements  are  the  bill  number.  Trip  Number, 
and  Transportation  Request  Number. 

In  addition,  for  the  update  transaction  for  a bad 
check,  the  CD  number  and  voucher  number  from  the  template 
must  be  added  to  both  the  accounts  receivable  record  and  the 
performance  record.  Only  the  CD  number  and  voucher  number 
of  the  last  transaction  affecting  the  records  must  be 
maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  describes  the  standard  online 
responses  and  error  messages  required  in  the  bad  check  or 
write-off  process. 

2.13.1.6  Deposit fund payment.  The  deposit  fund 

payment  process  inputs  and  records  payments  of  receivables 
applied  to  the  80X6875  deposit  fund  suspense  account.  These 
payments  may  be  made  to  return  money  to  an  organization 
sending  in  money  that  was  not  JSC’s  or  to  disburse  some 
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small  miscellaneous  payments  such  as  Federal  taxes  on 
telephone  calls. 

The  deposit  fund  payment  process  consists  of  a payment 
transaction,  an  update  transaction,  and  a correction 
transaction  defined  as  follows: 

• Payment  - a transaction  that  records  the  payment. 

• Update  - a transaction  that  updates  the  payment. 
The  transaction  must  have  been  directed  by  written 
documentation. 

• correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  payment  or  update 
transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-22  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
deposit  fund  payment  process.  Figure  2.13-23  defines  the 
template  required  for  input  of  these  data  elements. 

The  payment  transaction  is  specified  by  the  entry  of 
payment  dollars;  the  amount  entered  must  be  positive.  The 
update  transaction  is  specified  by  the  update  indicator  and 
the  entry  of  payment  dollars;  the  amount  entered  may  be 
either  positive  or  negative.  The  correction  transaction  is 
specified  by  the  correction  indicator;  any  data  elements 
that  are  incorrect  may  be  entered.  Only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 
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Data 

element 

Element 

required 

Source 

Error 

tl£e_ 

'As  of 
Date 

Optional 

User  supplied 

Fatal 

Bill  number 

Yes 

Various 

documents 

Fatal 

Payment 

dollars 

Conditional 

Various 

documents 

Fatal 

Voucher 

number 

Conditional 

User  supplied 

Fatal 

Update 

Optional 

User  supplied 

Fatal 

Correction 

Optional 

User  supplied 

Fatal 

Error 

Input/Edit  requirements  code_ 

Date  providing  for  the  backdating  cf  transactions.  B100 

Input  only  when  a transaction  date  other  than  the  B101 

system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

Input  for  all  payment,  update,  and  correction  C100 

transactions.  Positions  1 through  6 must  be  C101 

numeric.  Positions  7 and  8 must  be  numeric  or 
blank.  Positions  9 and  10  must  be  blank. 

Input  for  all  payment  and  update  transactions  B600 

and  for  correction  transactions  when  it  is  to  B601 

be  corrected.  For  a payment  transaction,  must  B602 

be  numeric  and  greater  than  0.  For  an  update  B604 

or  correction  transaction,  must  be  numeric  and 
not  equal  to  0. 

Input  for  all  payment  and  update  transactions  B930 

and  for  correction  transactions  when  it  is  to  B931 

be  corrected.  Position  1 must  be  J , and  posi- 
tions 2 through  4 must  be  numeric,  or  all  must  be 
numeric. 

Transaction  modifier  indicating  that  the  trans-  B062 


action  is  an  update.  Input  only  when  the  trans- 
action is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

Transaction  modifier  indicating  that  the  trans-  B062 

action  is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update  and 
correction  must  not  be  specified. 


Figure  2.13-22.  - Deposit  Fund  Payment  input  and  edit  requirements. 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / — 

♦♦♦♦TEMPLATE  uo.  Q6  - DEPOSIT  FUND  PAYMENT 
BILL  NO. - 

PAYMENT  $ , ± VOUCHEE  NO. 

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION 


Figure  2.13-23.  - Deposit  Fund 
Payment  template. 
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Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs. 


The  payment  transaction  inputs  and  records  the  payment. 
Each  transaction  must  update  an  accounts  receivable  record 
and  a deposit  fund  performance  record.  The  payment  amount 
from  the  template  must  update  the  payment  amount  from  the 
accounts  receivable  record.  The  accounts  receivable  record 
is  defined  by  the  bill  number.  For  the  payment  transaction, 
the  record  must  exist  and  be  open.  The  updated  payment 
amount  must  not  exceed  the  CD  amount  without  the  negative 
sign.  The  payment  amount  from  the  template  must  also  update 
the  payment  amount  from  the  deposit  fund  performance  record. 
The  deposit  fund  performance  record  is  defined  by  the  PR 
Number  and  Suffix  obtained  from  the  accounts  receivable 
record.  For  the  payment  transaction,  the  record  must  exist 
and  be  open.  The  updated  payment  amount  must  not  exceed  the 
CD  amount  without  the  negative  sign. 

In  addition,  the. voucher  number  from  the  template  must 
be  added  to  both  the  accounts  receivable  record  and  the 
deposit  fund  performance  record.  Only  the  voucher  number  of 
the  last  transaction  affecting  the  record  must  be 
maintained. 

2 pdate  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
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elements.  For  both  the  update  and  correction  transactions, 
the  deposit  fund  performance  and  accounts  receivable  records 
must  exist,  must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction,  except  the  amount 
entered  on  the  template  may  be  either  positive  or  negative. 
Amounts  from  the  deposit  fund  performance  and  accounts 
recievable  records  must  be  increased  or  reduced.  The  normal 
processing  edits  must  be  satisfied;  in  addition,  a negative 
change  must  not  reduce  any  of  the  amounts  from  either  of  the 
records  below  0.  For  the  deposit  fund  payment  process,  the 
only  dollar  data  element  is  payment  dollars.  The  processing 
requirement  for  the  correction  of  information  data  elements 
specifies  that  the  new  value  of  the  element  be  overlaid  on 
the  old.  The  only  information  data  element  is  the  voucher 
number.  If  any  of  the  control  data  elements  are  entered 
incorrectly,  the  transaction  must  be  reversed  and  a new 
transaction  entered.  The  only  control  data  element  is  the 
bill  number. 

In  addition,  for  the  update  transaction,  the  voucher 
number  from  the  template  must  be  added  to  both  the  accounts 
receivable  record  and  the  deposit  fund  performance  record. 
Only  the  voucher  number  of  the  last  transaction  affecting 
the  records  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 
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Output  - Section  2.13.2  describes  the  standard  online 
responses  and  error  messages  reguired  in  the  deposit  fund 
payment  process. 

2.13.1.7  Deposit  fund  transfer.  The  deposit  fund 
transfer  process  inputs  and  records  the  transfer  of  a 
receivable  from  a deposit  fund  receivable  to  a travel, 
commercial,  payroll,  or  miscellaneous  receipt  receivable. 
The  receivable  nay  be  transferred  either  after  the 
liquidation  and  before  the  deposit  or  after  the  deposit. 

The  deposit  fund  transfer  process  consists  ' of  a 
transfer  transaction,  an  update  transaction,  and  a 
correction  transaction  defined  as  follows:  ‘ 

• Transfer  - a transaction  that  transfers  the 
receivable. 

• Update  - a transaction  that  reverses  the  transfer  of 
the  receivable.  The  transaction  oust  have  been 
directed  by  written  documentation. 

• Correction  - a transaction  that  reverses  the 
transfer  of  the  receivable. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.  13-24  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
deposit  fund  transfer  process.  Figure  2.13-25  defines  the 
template  required  for  input  of  these  data  elements. 
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Data  Element  Error 

element  required  Source 


Input/Edit  requirements 


Error 

code 


o Q 

gg 


K> 

bJ 

I 

UD 

CD 


•As  of 
Date 

Optional 

User  supplied 

Fatal 

Date  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

B 1 00 
B 1 0 1 

Bill  number 

Yes 

Various 

documents 

Fatal 

Bill  number  for  transferor  bill.  Input  for  all 
transfer,  update,  and  correction  transactions. 
Positions  1 througn  6 must  be  numeric.  Posi- 
tions 7 and  8 must  be  numeric  or  blank.  Po- 
sitions 9 and  10  must  be  blank. 

C100 

C101 

Transfer 

dollars 

Yes 

Various 

documents 

Fatal 

Input  for  all  transfer,  update,  and  correction 
transactions.  For  a transfer  transaction,  must 
be  numeric  and  greater  than  0.  For  an  update 
or  correction  transaction,  must  be  numeric  and 
less  than  0. 

B600 

B601 

B604 

B607 

Type  of 

receivable: 

travel 

Conditional 

User  supplied 

Fatal 

Input  for  all  travel  transfer,  update,  and 
correction  transactions. 

C360 

Bill  number 

Conditional 

Various 

documents 

Fatal 

Bill  number  for  transferee  bill.  Input  for  all 
travel  transfer,  update,  and  correction  trans- 
tions.  The  first  six  positions  must  be  a TA 
number;  the  first  position  must  be  alphabetic 
and  the  remaining  five  must  be  numeric.  The 
last  four  positions  must  be  a type  of  travel 
activity;  the  first  three  positions  must  be 
numeric,  and  the  fourth  must  be  alphabetic.  See 
figure  2.12-2  for  additional  edits. 

C100 

C101 

Trip  Number 

Conditional 

Various 

documents 

Fatal 

Input  for  travel  transfer,  update,  and  correction 
transactions  when  the  receivable  is  for  a 
specific  trip  number  within  a General  Travel 
Authorization.  Must  be  numeric. 

C010 

C011 

Transporta- 

tion 

Request 

Humber 

Conditional 

Various 
documen ts 

Fatal 

Input  for  travel  transfer,  update,  and  correction 
transactions  when  the  receivable  is  for  a trans- 
portation activity  and  there  is  more  than  one 
Transportation  Reguest  Number  for  the  travel  order. 
The  first  position  must  be  alphabetic;  the  remain- 
ing seven  must  be  numeric.  See  figure  2.12-2  for 
additional  edits. 

C 02  0 
C021 

Name  code 

Conditional 

Various 

documents 

Fatal 

Input  for  all  travel  transfer  transactions. 
Must  be  a valid  name  code. 

C 04  0 
C041 

Reimbursement 

Conditional 

User  supplied 

None 

Transaction  modifier  indicating  that  the  receiv- 
able is  a reimbursement.  Input  only  when  the 
receivable  is  a reimbursement. 

None 

Type  of 
receivable: 

Conditional 

User  supplied 

Fatal 

Input  for  all  commercial  transfer,  update,  and 
correction  transactions. 

C360 

commercial 


* '"A 


Figure  2. 13-24.  - Deposit  Fund  Transfer  input  and  edit  requirements. 


Data 

element 

Element 

reaaired 

Source 

Error 

/Edit  requirements 

Bill  number 

Conditional 

Various 

documents 

Fatal 

£ss:;.  ”*« 

sitions  9 and  10  must  be  blank. 

Purchase 

Bequest 

Humber 

Conditional 

Various 

documents 

Fatal 

Input  for  all  commercial  transfer,  update,  and 
correction  transactions.  Positions  1 through  8 

nust’be  numeric.  Position  9 must  be  alphabetrc 
or  blank. 

Suffix 

Conditional 

Various 

documents 

Fatal 

Tnnut  for  commercial  transfer,  update,  and 
correction  transactions  when  other  than  the  base 
Suffix.  Must  be  numeric. 

Deposit  on 
containers 

Conditional 

User  supplied 

Fatal 

ass-raws  aJTArsr sa— 

is  a reimbursement. 

Reimbursement 

Conditional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the 
receivable  is  a reimbursement.  I»P»t  only  uhen 

the  receivable  is  a reimbursement.  Must  not  be 

Spot  Uhen  the  receivable  is  for  a deposit  on 
containers. 

Type  of 
receivable: 

payroll 
Pill  number 

Conditional 

Conditional 

User  supplied 

Various 

documents 

Fatal 

Fatal 

Input  for  all  payroll  transfer,  update,  and 
correction  transactions. 

Bill  number  for  transferee  bill.  Input  for  all 
payroll  transfer,  update,  and  correction  trans 
actions.  Positions  1 through  6 must  be  numeric. 
Positions  7 and  8 must  be  numeric  or  blank.  Po- 
sitions  9 and  10  must  be  blank. 

Method  of 
Authority 

Conditional 

Various 

documents 

Fatal 

input  for  all  payroll  transfer,  update,  and 
correction  transactions.  Must  be  a vali  tt 

but  not  97.  Must  be  a reimbursable  MA  if 
receivable  is  a reimbursement. 

program  Year 

Conditional 

various 

documents 

Fat  al 

input  for  payroll  transfer,  update,  and 

correction  transactions  when  e*  ^ oth«^ J^an 

the  current  PY.  Must  be  a valid  PY.  Also 
validated  with  FS  and  PWC. 

Object  Class 

Conditional 

Various 
documen  ts 

Fatal 

-^L^onalLrsrc^1onrnfuest'bUe^av:iidnaobject 

class. 

Primary  Work 
Code 

Conditional 

Various 

documents 

Fatal 

Incut  for  all  payroll  transfer,  update,  and 
correction  transactions.  Must  be  "“e  sES 

and  a valid  PSC.  Also  validated  with  PY  and  ES. 

Error 

code 


C100 

C101 


B300 

3301 


B311 


C37  0 


C370 


C360 


C100 

C101 


B 1 1 0 
Bill 
B114 
B1 1 5 

E 1 20 

B121 

C508 


B 1 90 
B191 


B17  0 
B 17  1 
E174 
C508 


Figure  2. 13-24.  - Deposit 


Fund  Transfer  input  and  edit 


requirements  (continued)  * 


Data 

eleaent 


Performing 

Organization 


F.eiaburseaent 


Type  of 
receivable: 
miscellaneous 
receipt 

Bill  number 


Program  Year 


Account 

symbol 


Update 


Correction 


Error 


Element 

required 

Source 

Error 

tVD§_ 

Tnput/Zdit  reguirenents 

code 

Conditional 

Various 

documents 

Fatal 

Input  for  all  payroll  transfer,  update,  and 
correction  transactions.  bust  be  a valid 
Perforaing  organization. 

B320 

3321 

Conditional 

User  supplied 

Hone 

Transaction  aodifier  indicating  that  the  re- 
ceivable is  a reimbursement-  Input  only  when 
the  receivable  is  a reimbursement . 

Hone 

Conditional 

User  supplied 

Fatal 

Input  for  all  aiscellaneous  receipt  transfer, 
update,  and  correction  transactions. 

C360 

Conditional 

Various 

docuaents 

Fatal 

bill  number  for  transferee  bill.  Input  for  all 
aiscellaneous  receipt  transfer,  update,  and  cor 
rection  transactions.  Positions  1 through  6 
must  be  numeric.  Positions  7 and  8 must  be  nu® 
eric  or  blank.  Positions  9 and  10  must  be  blank. 

C10G 

C101 

Conditional 

User  supplied 

Fatal 

Input  for  miscellaneous  receipt  transfer,  up- 
date, and  correction  transactions  when  PI  xs 
other  than  the  current  PI.  Kust  be  a valid  PI. 

El  20 
El  21 

Conditional 

Various 

docuaents 

Fatal 

Input  for  all  miscellaneous  receipt  transfer, 
update,  and  correction  transactions.  Bust  be 
a valid  account  symbol.  * 

Cl  20 
C121 

Optional 

User  supplied 

Fatal 

Transaction  aodifier  indicating  that  the  trans- 
action is  an  update.  Input  only  when  the 
transaction  is  an  update.  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 

B062 

figure  2-13*24.  - Deposit  Fuad  Transfer  input  and  edit  reguirenents  (concluded). 


+***IFMS  SEPTEMBER  30, 
****TEMPI,ATE  NO.  Q7  - 

BILL  NO.  

TYPE  OF  RECEIVABLE 
TRAVEL 


COMMERCIAL 


PAYROLL 

MISC  RECEIPT 
FOR  CHANGES  ONLY: 


1974  AS  OF  / / 

DEPOSIT  FOND  TRANSFER 
TRANSFER  $ , , . ± 

BILL  NO. - TRIP  NO. 

TRANS  REQUEST  NO.  NAME  CODE 

REIMBURSEMENT 

BILL  NO.  - 

PURCHASE  BEQUEST  NO.  SUFFIX 

DEPOSIT  ON  CONTAINERS  _ REIMBURSEMENT 

BILL  NO. - MA PY  OBJECT  CLASS 

PWC PERF  ORG REIMBURSEMENT 

BILL  NO. - PY ACCOUNT  SYMBOL 

UPDATE  _ CORRECTION 


Figure  2.13-25.  - Deposit  Fund  Transfer  template. 
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The  transfer  transaction  is  specified  by  the  entry  of 
transfer  dollars;  the  amount  entered  must  be  positive.  The 
update  transaction  is  specified  by  the  update  indicator  and 
the  entry  of  transfer  dollars;  the  amount  entered  must  be 
negative.  The  correction  transaction  is  specified  by  the 
correction  indicator  and  the  entry  of  transfer  dollars;  the 
amount  entered  must  be  negative.  Only  one  of  the  three 
transactions  may  be  entered  at  any  one  time. 

Processing  - The  processing  requirements  are  discussed 
by  transaction  in  the  following  paragraphs: 

Transfer 

The  transfer  transaction  inputs  and  records  the 
transfer  of  the  receivable.  Each  transaction  must  update  an 
accounts  receivable  record,  at  least  two  performance 
records,  and  possibly  a contract  record  and  letter  of  credit 
records. 

The  transfer  transaction  must  reverse  the  original 
entries  for  the  establishment,  cash  collection,  and  deposit 
of  the  receivable.  The  transfer  amount  from  the  template 
must  be  equal  to  the  establishment  amount  from  the  accounts 
receivable  record.  The  accounts  receivable  record  is 
defined  by  the  transferor  bill  number  and  the  deposit  fund 
performance  record  by  the  PR  Number  and  Suffix  obtained  from 
the  accounts  receivable  record.  For  the  transfer 
transaction,  both  records  must  exist  and  be  open. 

If  the  receivable  is  being  transferred  to  a travel 
receivable,  the  establishment  amount,  cash  collection 
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amount,  and  CD  amount  from  the  accounts  receivable  record 
must  all  be  reduced  to  0,  and  a new  accounts  receivable 
record  must  be  created  with  the  data  elements  described  in 
section  2.13.1.1.1.  In  addition,  the  transfer  amount  must 
be  reversed  from  the  deposit  fund  performance  record  and 
must  update  the  travel  performance  record  as  a normal  travel 
establishment,  cash  collection,  and  deposit.  The  new 
accounts  receivable  record  is  defined  by  the  transferee  bill 
number.  Trip  Number,  and  Transportation  Request  Number;  for 
the  transfer  transaction,  the  record  may  or  may  not  already 
exist.  The  travel  performance  record  is  defined  by  the  TA 
Number,  type  of  travel  activity.  Trip  Number,-  and 
Transportation  Bequest  Number  (as  discussed  in  section 
2.13.1.1.1);  for  the  transfer  transaction,  the  record  must 
exist  and  be  open.  All  of  the  processing  requirements  for  a 
travel  establishment,  cash  collection,  and  deposit  discussed 
in  sections  2.13.1.1.1,  2.13.1.2,  and  2.13.1.3.1  apply. 

If  the  receivable  is  being  transferred  to  a commercial 
receivable,  the  establishment  amount,  cash  collection 
amount,  and  CD  amount  from  the  accounts  receivable  record 
must  all  be  reduced  to  0,  and  a new  accounts  receivable 
record  must  be  created  with  the  data  elements  described  in 
section  2.13.1.1.2.  In  addition,  the  transfer  amount  must 
be  reversed  from  the  deposit  fund  performance  record  and 
must  update  the  contract,  performance,  and  letter  of  credit 
records  as  a normal  commercial  establishment,  cash 
collection,  and  deposit.  The  new  accounts  receivable  record 
is  defined  by  the  transferee  Mil  number;  for  the  transfer 
transaction,  the  record  may  or  may  not  already  exist.  The 
contract  record  is  defined  by  the  Contract/Order  Number 
obtained  from  the  performance  record  and  the  performance 
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record  by  the  PR  Number  and  Suffix  entered  on  the  template; 
for  the  transfer  transaction,  both  records  must  exist  and  be 
open.  All  of  the  processing  requirements  for  a commercial 
establishment,  cash  collection,  and  deposit  discussed  in 
sections  2.13.1.1.2,  2.13.1.2,  and  2.13.1.3.2  apply. 

If  the  receivable  is  being  transferred  to  a payroll 
receivable,  the  establishment  amount,  cash  collection 
amount,  and  CD  amount  from  the  accounts  receivable  record 
must  all  be  reduced  to  0,  and  a new  accounts  receivable 
record  must  be  created  with  the  data  elements  described  in 
section  2.13.1.1.3.  In  addition,  the  transfer  amount-  must 
be  reversed  from  the  deposit  fund  performance  record  and 
must  create  or  update  the  payroll  performance  record  as  a 
normal  payroll  establishment,  cash  collection,  and  deposit. 
The  new  accounts  receivable  record  is  defined  by  the 
transferee  bill  number;  for  the  transfer  transaction,  the 
record  may  or  may  not  already  exist.  The  payroll 
performance  record  is  defined  by  a PR  Number  and  Suffix 
generated  by  the  system  from  MA,  PY,  Object  Class,  PWC,  and 
Performing  Organization  entered  on  the  template.  All  of  the 
processing  requirements  for  a payroll  establishment,  cash 
collection,  and  deposit  discussed  in  sections  2.13.1.1.3, 
2.13.1.2,  and  2.13.1.3.3  apply. 

If  the  receivable  is  being  transferred  to  a 
miscellaneous  receipt  receivable,  the  establishment  amount, 
cash  collection  amount,  and  CD  amount  from  the  accounts 
receivable  record  must  be  created  with  the  data  elements 
described  in  section  2.13.1.1.4.  In  addition,  the  transfer 
amount  must  be  reversed  from  the  deposit  fund  performance 
record  and  must  create  or  update  the  miscellaneous  receipt 
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performance  record  as  a normal  Miscellaneous  receipt 
establishment,  cash  collection,  and  deposit.  The  new 
accounts  receivable  record  is  defined  by  the  transferee  bill 
number;  for  the  transfer  transaction,  the  record  may  or  may 
not  already  exist.  The  miscellaneous  receipt  performance 
record  is  defined  by  a PR  Number  and  Suffix  generated  by  the 
system  from  PY  and  account  symbol  entered  on  the  template. 
All  the  processing  requirements  for  a miscellaneous  receipt 
establishment,  cash  collection,  and  deposit  discussed  in 
sections  2.13.1.1.4,  2.13.1.2,  and  2.13.1.3.4  apply. 


npdate  and  Correction 

Updates  and  corrections  are  made  to  control  data 
elements.  For  both  the  update  and  the  correction 
transaction,  the  performance,  contract,  and  accounts 
receivable  records  must  exist,  must  be  open,  and  must  be 
changed  appropriately. 

If  any  of  the  control  data  elements  are  entered 
incorrectly,  the  transaction  must  be  reversed  and  a new 
transaction  entered.  The  control  data  elements  are  the  bill 
numbers.  Trip  Number,  Transportation  Request  Number,  and  the 
reimbursement  indicator  for  travel  transfers;  the  bill 
numbers,  PR  Number,  Suffix,  the  deposit  on  containers 
indicator,  and  the  reimbursement  indicator  for  commercial 
transfers;  the  bill  numbers,  HA,  PY,  Object  Class,  PNC, 
Performing  organization,  and  the  reimbursement  indicator  for 
payroll  transfers;  and  the  bill  numbers,  PY,  and  account 
symbol  for  miscellaneous  receipt  transfers. 


JK 
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To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  deposit  fund 
transfer  process. 

2.13.1.8  Aircraft  spares.  The  aircraft  spares  process 
inputs  and  records  aircraft  spares  activity.  The  aircraft 
spares  process  is  divided  into  an  establishment  activity,  a 
variance  activity,  and  a cash  collection  or  voucher 
deduction  activity. 

Aircraft  spares  no  longer  needed  by  JSC  are  sent  to 
various  government  depots  for  credit.  It  is  estimated  that 
credit  will  be  received  in  an  amount  equal  to  60  percent  of 
the  original  value  of  the  spares.  The  various  accounts  that 
originally  funded  the  purchase  of  the  spares  are  given 
credit,  the  balance  of  the  supply  carrier  is  reduced  to 
"lend"  funds  to  the  various  accounts  pending  receipt  of  the 
credit,  and  an  aircraft  spares  receivable  is  established. 

Credit  received  for  the  spares  is  normally  in  an  amount 
different  from  the  original  60  percent  amount.  The 
difference  is  termed  the  variance.  The  receivable,  the 
credit  given  to  the  various  accounts  that  originally  funded 
the  purchase  of  the  spares,  and  the  amount  lent  by  the 
supply  carrier  must  all  be  corrected  by  the  variance. 
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Credit  received  for  the  spares  may  be  by  cash 
collection  or  by  voucher  deduction  as  an  offset  to  a 
MILS TRIP /FED STRIP  voucher,  h cash  collection  is  recorded  as 
a deposit  fund  establishment,  cash  collection,  and  deposit 
until  the  variance  is  determined  and  the  aircraft  spares 
receivable  corrected,  at  which  tine  the  cash  collection  and 
deposit  are  transferred  from  the  deposit  fund  receivable  to 
the  aircraft  spares  receivable.  A voucher  deduction  is  not 
recorded  until  the  variance  is  determined  and  the  aircraft 
spares  receivable  corrected,  at  which  time  it  is  applied 
directly  to  it. 

The  aircraft  spares  process  consists  of  an 
establishment  transaction,  a cash  collection  transaction,  a 
voucher  deduction  transaction,  an  update  transaction,  and  a 
correction  transaction  defined  as  follows: 

• Establishment  - a transaction  that  records  the 
establishment  of  the  aircraft  spares  receivable  and 
the  borrowing  of  funds  from  the  supply  carrier. 
This  transaction  may  be  used  for  either  the  initial 
establishment  of  the  receivable  or  the  variance. 

• cash  collection  - a transaction  that  records  a 
liquidation  of  the  aircraft  spares  receivable  by  the 
transfer  of  the  cash  collection  and  deposit  from  the 
deposit  fund  receivable  to  the  aircraft  spares 
receivable. 

• Voucher  deduction  - a transaction  that  records  a 
liquidation  of  the  aircraft  spares  receivable  by  a 
voucher  deduction. 

• Update  - a transaction  that  updates  the 
establishment,  the  transfer  of  the  cash  collection 
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and  deposit,  or  the  voucher  deduction.  The 
transaction  must  have  been  directed  by  written 
documentation. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  either  the  establishment,  cash 
collection,  voucher  deduction,  or  update 
transaction. 

The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.13-26  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
aircraft  spares  process.  Figure  2.13-27  defines  the 
template  required  for  input  of  these  data  elements. 

The  establishment  transaction  is  specified  by  the 
establishment  indicator  and  the  entry  of  the  dollar  amount; 
the  amount  entered  may  be  either  positive  or  negative.  The 
cash  collection  transaction  is  specified  by  the  cash 
collection  indicator  and  the  entry  of  the  dollar  amount;  the 
amount  entered  must  be  positive.  The  voucher  deduction 
transaction  is  specified  by  the  voucher  deduction  indicator 
and  the  entry  of  the  dollar  amount;  the  amount  entered  must 
be  positive.  The  update  transaction  is  specified  by  the 
update  indicator,  the  establishment,  cash  collection,  or 
voucher  deduction  indicator,  and  the  entry  of  the  dollar 
amount;  the  amount  entered  may  be  either  positive  or 
negative.  The  correction  transaction  is  specified  by  the 
correction  indicator,  and  the  establishment,  voucher 
deduction,  or  cash  collection  indicator;  any  data  elements 
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Error 


Error 

code 


Input/Edit  requirements 


Fatal  Date  providing  for  the  backdating  of  transactions. 

Input  only  when  a transaction  date  Gther  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits- 

Fatal  Input  for  all  establishment,  cash  collection, 
voucher  deduction,  and  update  transactions  and 
for  correction  transactions  when  it  is  to  be 
corrected.  For  a cash  collection  or  voucher  de- 
duction transaction,  must  be  numeric  and  greater 
than  0.  For  an  establishment,  update,  or 
correction  transaction,  must  be  numeric  and  not 
egual  to  0. 

Fatal  Input  for  all  establishment  transactions  and 

for  update  or  correction  transactions  when  up- 
dating or  correcting  the  establishment.  Only 
one  of  the  three  types  of  transactions  may  be 
entered  at  any  one  time. 

Fatal  Input  for  all  establishment  transactions  and  for 
update  or  correction  transactions  when  updating 
or  correcting  the  establishment.  Positions  1 
through  8 must  be  numeric.  Position  9 must  be 
alphabetic  or  blank. 

Fatal  Input  for  establishment,  update,  and  correction 
transactions  when  other  than  the  base  Suffix. 

Must  be  numeric. 

Fatal  Input  for  establishment  and  update  transactions 
when  the  receivable  is  established  or  modified 
from  a bill  and  for  correction  transactions  when 
the  receivable  is  established  or  modified  from 
a bill  and  it  is  to  be  corrected.  Positions 

1 through  6 must  be  numeric.  Positions  7 and  8 
must  be  numeric  or  blank.  Positions  9 and  10  must 
be  blank.  Both  the  bill  number  and  voucher 
number  must  not  be  specified  in  the  same 
transaction. 

Fatal  Input  for  establishment  and  update  transactions 
when  the  receivable  is  modified  from  a voucher 
and  for  correction  transactions  when  the  receivable 
is  modified  from  a voucher  and  it  is  to  be  cor- 
rected- Position  1 must  be  J , and  positions 

2 through  4 must  be  numeric,  or  all  must  be  num- 
eric. Both  the  bill  number  and  voucher  number 
must  not  be  specified  in  the  same  transaction. 

Fatal  Input  for  all  cash  collection  transactions  and 
for  update  or  correction  transactions  when 
updating  or  correcting  the  cash  collection. 

Only  one  of  the  three  types  of  transactions  may 
be  entered  at  any  one  time. 


B100 
B 1 0 1 


B600 

B601 

B602 

B604 


B010 
B0 1 1 


B300 

B301 


B311 


C100 
C101 
Cl  02 


B930 
B93 1 
B932 


B010 

BOH 


Aircraft  Scares  input  and  edit  r -auirenents. 


Data 

element 

Element 

required 

Source 

Error 

type 

Input/Edit  requirements 

Error 

code 

Bill 

number 

Conditional 

Various 

documents 

Fatal 

Input  for  all  cash  collection  transactions,  and 
for  update  or  correction  transactions  when 
updating  or  correcting  the  cash  collection. 
Positions  1 through  6 must  be  numeric.  Positions 
7 and  S must  be  numeric  or  blank.  Positions  9 
and  10  must  be  blank. 

C100 

C101 

Type  of 
transaction: 
voucher 
deduction 

Conditional 

User  supplied 

Fatal 

Input  for  all  voucher  deduction  transactions  and 
for  update  and  correction  transactions  when  up- 
dating or  correcting  the  voucher  deduction.  Only 
one  of  the  three  types  of  transactions  may  be 
entered  at  any  one  time. 

B010 
B0 1 1 

Voucher 

number 

Conditional 

Various 

documents 

7atal 

Input  for  all  voucher  deduction  transactions  and 
for  update  and  correction  transactions  when  up- 
dating or  correcting  the  voucher  deduction. 
Position  1 must  be  J , and  positions  2 through  4 
must  be  numeric,  or  all  must  be  numeric. 

B930 

B931 

Update 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  an  update-  Input  only  when  the  trans- 
action is  an  update-  Both  the  update  and 
correction  must  not  be  specified. 

B062 

Correction 

Optional 

User  supplied 

Fatal 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction.  Both  the  update 
and  correction  must  not  be  specified. 

B062 

figure  2.13-26.  - Aircraft  Spares  input  and  edit  rcquirenents  {conclude!). 


♦#**XFMS  SEPTEMBER  30,  1974  AS  OF  — / — / — 
♦♦♦♦TEMPLATE  NO.  Q8  - AIRCRAFT  SPARES 

AMOUNT  $ t » • — ± 

TYPE  OF  TRANSACTION: 

ESTABLISHMENT  _ PURCHASE  REQUEST  NO.  

BILL  NO. VOUCHER 

CASH  COLLECTION  _ BILL  NO. — 

VOUCHER  DEDUCTION  _ VOUCHER  NO.  

FOR  CHANGES  ONLY:  UPDATE  _ CORRECTION  _ 


SUFFIX 
NO.  


Figure  2.13-27.  - Aircraft  Spares  template. 
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that  are  incorrect  may  be  entered.  Only  one  of  the  four 
transactions  may  be  entered  at  any  one  time. 

Processing  - The  specific  transaction  requirements  are 
discussed  by  transaction  in  the  following  paragraphs. 

Establishment 

The  establishment  transaction  shifts  the  commitment, 
obligation,  cost,  and  disbursement  from  the  PR  that 
originally  purchased  the  parts  to  the  PR  for  the  supply 
carrier  and  establishes  the  aircraft  spares  receivable. 
Each  transaction  must  update  both  performance  records,  the 
appropriate  PWA  accounts,  and  the  aircraft  spares  accounts 
receivable  record. 

The  dollar  amount  from  the  template  must  reduce  the 
commitment,  obligation,  cost,  and  disbursement  from  the 
performance  record  defined  by  the  PR  Number  and  Suffix 
entered  on  the  template  and  must  update  the  commitment, 
obligation,  cost,  disbursement,  and  establishment  amount 
from  the  supply  carrier  performance  record.  For  the 
establishment  transaction,  both  records  must  exist  and  be 
open.  None  of  the  amounts  may  be  reduced  below  0.  The 
funds  must  be  returned  to  or  obtained  from  the  PWA  account 
specified  by  the  accounting  information  of  the  performance 
record.  The  issues  or  balance  of  the  PWA  account  must  be 
sufficient. 

The  dollar  amount  from  the  template  must  also  update 
the  establishment  amount  from  the  aircraft  spares  accounts 
receivable  record.  For  the  establishment  transaction,  the 
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record  must,  exist  and  be  open.  In  addition,  the  bill  number 
from  the  template  must  be  added  to  the  accounts  receivable 
record.  Only  the  bill  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

The  processing  requirements  discussed  in  the  preceding 
paragraphs  are  for  the  initial  establishment  of  the  60 
percent  amount.  The  establishment  of  a positive  variance  is 
the  same  except  that  the  information  may  be  from  either  a 
bill  or  a voucher.  The  establishment  of  a negative  variance 
is  the  opposite. 

Cash  Collection 

The  cash  collection  transaction  records  the  liquidation 
of  the  aircraft  spares  receivable  by  the  transfer  of  the 
cash  collection  and  deposit  from  the  deposit  fund  receivable 
established  to  record  the  receipt  of  the  cash  to  the 
aircraft  spares  receivable.  Each  transaction  must  update 
both  accounts  receivable  records,  the  supply  carrier 
performance  record,  and  the  appropriate  PWA  account. 

The  dollar  amount  from  the  template  must  (1)  reduce 
the  establishment  amount  and  the  cash  collection  amount  and 
increase  the  CD  amount  from  the  accounts  receivable  record 
defined  by  the  bill  number  entered  on  the  template  and  (2) 
increase  the  cash  collection  amount  and  reduce  the  CD  amount 
from  the  aircraft  spares  accounts  receivable  record.  For 
the  cash  collection  transaction,  both  records  must  exist  and 
be  open.  The  establishment  amount  and  cash  collection 
amount  must  not  be  reduced  below  0,  and  the  CD  amount  must 
not  be  increased  above  0.  The  updated  cash  collection 
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amount  from  the  aircraft  spares  receivable  record  plus  the 
voucher  deduction  amount  plus  the  write-off  amount  must  not 
exceed  the  establishment  amount.  In  addition,  the  bill 
number  from  the  template  must  be  added  to  the  aircraft 
spares  accounts  receivable  record.  Only  the  bill  number  of 
the  last  transaction  affecting  the  record  must  be 
maintained. 

The  dollar  amount  from  the  template  must  also  reduce 
the  commitment,  obligation,  cost,  and  disbursement  from  the 
supply  carrier  performance  record.  For  the  cash  collection 
transaction,  the  record  must  exist  and  be  open.  None  of  the 
amounts  may  be  reduced  below  0.  The  funds  must  be  returned 
to  the  PWA  account  specified  by  the  accounting  information 
of  the  performance  record.  The  issues  of  the  PWA  account 
must  be  sufficient. 


Voucher  Deduction 

9 

The  voucher  deduction  transaction  records  the 
liquidation  of  the  aircraft  spares  receivable  by  a voucher 
deduction.  Each  transaction  must  update  the  aircraft  spares 
accounts  receivable  record,  the  supply  carrier  performance 
record,  and  the  appropriate  PWA  account. 

The  dollar  amount  from  the  template  must  update  the 
voucher  deduction  amount  from  the  aircraft  spares  accounts 
receivable  record.  For  the  voucher  deduction  transaction, 
the  record  must  exist  and  be  open.  The  updated  voucher 
deduction  amount  plus  the  cash  collection  amount  plus  the 
write-off  amount  must  not  exceed  the  establishment  amount. 
In  addition,  the  voucher  number  from  the  template  must  be 
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added  to  the  aircraft  spares  accounts  receivable  record. 
Only  the  voucher  number  of  the  last  transaction  affecting 
the  record  must  be  maintained. 

The  dollar  amount  from  the  template  must  also  reduce 
the  commitment,  obligation,  cost,  and  disbursement  from  the 
supply  carrier  performance  record.  For  the  voucher 
deduction  transaction,  the  record  must  exist  and  be  open. 
None  of  the  amounts  may  be  reduced  below  0.  The  funds  must 
be  returned  to  the  PHA  account  specified  by  the  accounting 
information  of  the  performance  record.  The  issues  of  the 
PWA  account  must  be  sufficient. 

update  and  Correction 

Updates  are  made  to  either  dollar  data  elements  or 
control  data  elements;  corrections  are  made  to  either  dollar 
data  elements,  information  data  elements,  or  control  data 
elements.  For  both  the  update  and  correction  transactions, 
the  performance  and  accounts  receivable  records  must  exist, 
must  be  open,  and  must  be  changed  appropriately. 

The  processing  requirements  for  the  update  or 
correction  of  dollar  data  elements  are  basically  the  same  as 
those  for  the  original  transaction  except  that,  in  all 
cases,  the  amount  entered  on  the  template  may  be  either 
positive  or  negative.  Amounts  from  the  performance  and 
accounts  receivable  records  must  be  increased  or  reduced. 
Funds  must  be  obtained  from  or  returned  to  PHA  accounts. 
The  normal  processing  edits  must  be  satisfied;  in  addition, 
none  of  the  amounts  from  any  of  the  records  may  be  reduced 
below  0.  For  the  aircraft  spares  process,  the  only  dollar 
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data  element  is  the  dollar  amount.  The  processing 
requirement  for  the  correction  of  information  data  elements 
specifies  that  the  new  value  of  the  element  be  overlaid  on 
the  old.  The  information  data  elements  are  the  bill  number 
and  voucher  number  for  the  establishment  and  the  voucher 
number  for  the  voucher  deduction.  If  any  of  the  control 
data  elements  are  entered  incorrectly,  the  transaction  must 
be  reversed  and  a new  transaction  entered.  The  control  data 
elements  are  the  PR  Number  and  Suffix  for  the  establishment 
and  the  bill  number  for  the  cash  collection. 

In  addition,  for  the  update  transaction  for  the 
establishment,  the  bill  number  or  voucher  number  from  the 
template  must  be  added  to  the  accounts  receivable  record. 
For  the  update  transaction  for  the  cash  collection,  the  bill 
number  must  be  added.  For  the  update  transaction  for  the 
voucher  deduction,  the  voucher  number  must  be  added.  Only 
the  bill  number  or  voucher  number  of  the  last  transaction 
affecting  the  record  must  be  maintained. 

To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial,  update,  and  correction  transactions  must  be 
identified  in  the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  in  the  aircraft  spares 
process. 

2.13.1.9  Prior year reopening.  The  prior  year 

reopening  process  reopens  accounts  receivable  records  that 
were  closed  during  prior  years  and,  thus,  do  not  still 
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reside  on  the  performance  data  base.  Once  reopened,  the 
records  are  available  for  normal  processing.  If  the 
contract  and  performance  records  related  to  the  accounts 
receivable  record  have  been  closed,  they  must  be  reopened 
also. 


The  prior  year  reopening  process  consists  of  a 
reopening  transaction  and  a correction  transaction  defined 
as  fc„lows: 


• Reopening  - a transaction  that  reestablishes  the 
accounts  receivable  record. 

• Correction  - a transaction  that  corrects  any  data 
elements  entered  in  the  reopening  transaction. 


The  input,  processing,  and  output  requirements  for  these 
transactions  are  discussed  in  the  following  paragraphs. 

Input  - Figure  2.  13-28  contains  a list  of  data  elements 
that  must  be  input  and  edits  that  must  be  performed  for  the 
prior  year  reopening  process.  Figure  2.13-29  defines  the 
template  required  for  input  of  these  data  elements. 

The  reopening  transaction  is  specified  by  the  entry  of 
the  various  dollar  amounts;  the  amounts  entered  must  be 
positive.  The  correction  transaction  is  specified  by  the 
correction  indicator;  any  data  elements  that  are  incorrect 
may  be  entered. 

Processing  - The  specific  transaction  requirements  are 
discussed  by  transaction  in  the  following  paragraphs. 
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Data 

element 

Element 

required 

Source 

Error 
t ifie 

I n put /Ed. It  requirements 

•As  of 
Date 

Optional 

User  supplied 

Fatal 

Dare  providing  for  the  backdating  of  transactions. 
Input  only  when  a transaction  date  other  than  the 
system  date  is  desired.  When  input,  must  be  nu- 
meric and  conform  to  all  normal  date  edits. 

Bill  number 

Yes 

Various 

documents 

Fatal 

Input  for  all  reopening  and  correction  trans- 
actions. For  a travel  receivable,  the  first 
six  positions  must  be  a TA  number;  the 
position  must  be  alphabetic,  and  the  remaining 
five  must  be  numeric.  The  last  four  positrons 
must  be  a type  of  travel  activity;  the  first 
three  positions  must  be  numeric,  and  the  fourth 
must  be  alphabetic.  See  figure  2.12-2  for 
additional  edits.  For  all  other  receivables, ^ 
positions  1 through  6 must  be  numeric. . Positrons 
7 and  8 must  be  numeric  or  blank.  Positrons  9 
and  10  must  be  blank. 

Trip  Number 

Conditional 

Various 
documen  ts 

Fatal 

Input  for  travel  reopening  and  correction  # 

transactions  when  the  receivable  is  for  a specific 
trip  number  within  a General  Travel  Authorization. 
Must  be  numeric. 

transporta- 
tion Request 
Number 

Conditional 

Various 
documen  ts 

Fatal 

Input  for  travel  reopening  and  correction  trans- 
actions  when  the  receivable  is  for  a transportation 
activity.  The  first  position  oust  be  alphbetic; 
the  remaining  seven  must  be  numeric.  See  figure 
2.12-2  for  additional  edits- 

Establishment 

dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  all  reopening  transactions  and  for 
correction  transactions  when  it  is  to  be 
corrected.  For  a reopening  transaction,  must^ 
be  numeric  and  greater  than  0.  For  a correction 
transaction,  must  be  numeric  and  not  equal  to  0. 

Cash 

collection 

dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  reopening  transactions  when  there  is  a 
cash  collection  and  for  correction  transactions 
when  it  is  to  be  corrected.  For  a reopening 
transaction,  must  be  numeric  and  greater  than  0. 
For  a correction  transaction,  must  be  numeric 
and  not  egual  to  0.  Must  be  input  when  certi- 
ficate of  deposit  dollars  are  input. 

Voucher 

deduction 

dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  reopening  transactions  when  there  is  a 
voucher  deduction  and  for  correction  transactions 
when  it  is  to  be  corrected.  For  a reopening 
transaction,  must  be  numeric  and  greater  than  0. 
For  a correction  transaction,  must  be  numeric  and 

not  equal  to  0. 


Error 

code 


B100 
B 10  1 


C100 

C101 


C010 

con 


C020 

C021 


C130 
C131 
C 132 
C 134 


C 140 
C 1 4 1 
C142 
Cl  44 


C151 
Cl  52 
Cl  54 


Figure  2.13-28.  - Accounts 


Receivable  Prior  Year  Reopening  input  and  edit  requirements. 


/£  \ 

I ..  s 

V -* 


Data 

element 

Element 

required 

Source 

Error 
t i£e_ 

Input/Edit  requirements 

Error 

code 

Certificate 
of  deposit 
dollars 

Conditional 

Various 
docume nts 

Fatal 

Input  for  reopening  transactions  when  there  is  a 
deposit  and  for  correction  transactions  when  it 
Is  to  be  corrected.  For  a reopening  transaction, 
must  be  numeric  and  greater  than  0.  For  a 
correction  transaction,  must  be  numeric  and  not 
equal  to  0.  Must  be  input  when  cash  collection 
dollars  are  input. 

C160 
C 1 6 1 
Cl  62 
Cl  64 

Write-off 

dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  reopening  transactions  when  there  is 
a write-off  and  for  correction  transactions  when 
it  is  to  be  corrected.  For  a reopening  trans- 
action, must  be  numeric  and  greater  than  0.  For 
a correction  transaction,  must  be  numeric  and  not 
equal  to  0. 

C 17  1 
C 1 72 
C 17  4 

Bad  check 
dollars 

Conditional 

Various 

documents 

Fatal 

Input  for  reopening  transactions  when  ther*3  is  a 
bad  check  and  for  correction  * transactions  when  it 
is  to  be  corrected.  For  a reopening  transaction, 
must  be  numeric  and  greater  than  0.  For  a 
correction  transaction,  must  be  numeric  and  not 
equal  to  0. 

C101 
Cl  82 
Cl  84 

Type  of 
receivable 

yes 

User  supplied 

Fatal 

Indicator  specifying  whether  the  receivable  is  a 
travel,  commercial,  payroll,  or  miscellaneous 
receipt  receivable.  Only  one  type  of  receivable 
may  be  specified. 

Cl  90 
C 1 9 1 

Contract/ 

Order 

Number 

Conditional 

Various 

documents 

Fatal 

Input  for  all  commercial,  payroll,  and  miscel- 
laneous receipt  reopening  transactions  and  for 
commercial,  payroll,  and  miscellaneous  receipt 
correction  transactions  when  it  is  to  be 
corrected.  Must  have  a valid  prefix.  May  be 
either  a contract,  grant,  or  T-order  number,  or  a 
Contract/Order  Number  assigned  to  a payroll  or 
miscellaneous  receipt. 

B360 

B361 

Pu rchase 

request 

Number 

Conditional 

Various 

documents 

Fatal 

Input  for  all  commercial,  payroll,  and  miscel- 
laneous receipt  reopening  and  correction  trans- 
actions. Positions  1 through  8 must  be  numeric. 
Position  9 must  be  alphabetic  or  blank- 

B300 

B301 

Suffix 

Conditional 

Various 

documents 

Fatal 

input  for  commercial,  payroll,  and  miscellaneous 
receipt  transactions  when  other  than  the  base 
Suffix.  Must  be  numeric. 

B311 

Method  of 
Authority 

Condi feional 

Various 

documents 

Fatal 

Input  for  all  reopening  transactions  and  for 
corr°ction  transactions  when  it  is  to  be 
corrected.  Must  he  a valid  KA  but  not  97. 
Must  be  a reimbursable  MA  if  the  receivable 
is  a reimbursement. 

B 1 1 0 
Bill 
B11  4 
Eli  5 

FigurP  2.13-28.  - accounts  Receivable  Prior  Year  Reopening  input  and  edit  requirements  (continued). 


Data 

element 

Element 

required 

Source 

Error 

lZ£e_ 

Program  Year 

Conditional 

Various 

documents 

Fatal 

Fund  Source 

Conditional 

Various 

documents 

Fatal 

Date  of 
bill 

Conditional 

Various 

documents 

Fatal 

Account 

symbol 

Conditional 

Various 

documents 

Fatal 

Reimbursement 

Conditional 

User  supplied 

Fatal 

Refund 

Conditional 

User  supplied 

Fatal 

Deposit  on 
containers 

Conditional 

User  supplied 

Fatal 

Extent  of 
refund 

Conditional 

User  supplied 

Fatal 

Correction 

Optional 

User  supplied 

Hone 

Input/Edit  requirements 


Input  for  reopening  transactions  when  PY  is 
th s r than  the  current  PY  and  for  correction 
transactions  when  it  is  to  be  corrected.  Must 
be  a valid  PY . 

input  for  all  reopening  transactions  and  for 
correction  transactions  when  it  is  to  be 
corrected.  Must  be  a valid  FS.  Also  validate 
with  the  account  symbol  for  miscellaneous 
receipt  receivables. 

Input  for  all  reopening  transactions  and  for 
correction  transactions  when  it  is  to  be 
corrected.  Must  be  numeric  and  conform  to  all 
normal  date  edits. 

Input  for  all  miscellaneous  receipt  reopening 
transactions  and  for  miscellaneous  receipt 
correction  transactions  when  it  is  to  be  corrected. 
Must  be  a valid  account  symbol.  Also  validated 
with  FS. 

Indicator  specifying  that  the  receivable  is  a re- 
imbursement. Input  only  when  the  receivable  is  a 
reimbursement.  Must  not  be  input  when  the 
receivable  is  a refund  or  for  a deposit  on 
containers. 

Indicator  specifying  that  the  receivable  is  a 
refund.  Input  only  when  the  receivable  is  a 
refund.  Must  not  be  input  when  the  receivable 
is  a reimbursement - 

Indicator  specifying  that  the  receivable  is  for  a 
deposit  on  containers.  Input  only  when  the 
receivable  is  for  a deposit  on  containers.  Must 
not  be  input  when  the  receivable  is  a 
reimbursement. 

Indicator  specifying  whether  a refund  is  partial 
or  complete.  Must  not  be  input  when  the 
receivable  is  a reimbursement. 

Transaction  modifier  indicating  that  the  trans- 
action is  a correction.  Input  only  when  the 
transaction  is  a correction- 


Figure  2.13-28.  - Accounts  Receivable  Prior  Year  Reopening  input  and  edit  requirements  (concluded) 


Error 

code 


B120 
B121 
E 1 26 


B 1 30 
B 1 39 
C520 
C52 1 


C110 


C 1 20 
C 1 2 1 
C520 
C521 


C370 

C371 


C371 


C370 


Cl  95 
Cl  96 
Cl  97 

None 


****IFMS  SEPTEMBER  30,  1974  AS  OF  / / 

♦♦♦♦TEMPLATE  NO,  Q9  - ACCOUNTS  RECEIVABLE  PRIOR  YEAR  REOPENING 

BILL  NO.  - TRIP  NO.  TRANS  BEQUEST  NO.  

ESTABLISHMENT  S , , . ± CASH  COLLECTION  $ , , • — ± 

VOUCHER  DEDUCTION  $ , , • ± CD  $ , , ■ — ± 

WRITE-OFF  S , , . ± BAD  CHECK  $ , , • ± 

TYPE  OF  RECEIVABLE:  TR  _ CM  _ PA  _ MR  _ 

CONTRACT/ORDEB  NO.  PURCHASE  REQUEST  NO.  SUFFIX 

HA PY FS DATE  OF  BILL / / ACCOUNT  SYMBOL 

REIMBURSEMENT  _ REFUND  _ DEPOSIT  ON  CONTAINERS  _ 

EXTENT  OF  REFUND:  PARTIAL  _ COMPLETE  _ 

CORRECTION  _ 


Figure  2.13-29.  - Prior  Year  Reopening  template. 


The  reopening  transaction  inputs  and  records  the 
reopening.  Each  transaction  must  create  an  accounts 
receivable  record.  The  accounts  receivable  record  to  be 
reopened  is  defined  by  the  T A Number,  type  of  travel 
activity.  Trip  Number,  and  Transportation  Bequest  Number  for 
travel  receivables,  and  by  the  bill  number  for  all  other 
receivables.  For  the  reopening  transaction,  the  record  must 
not  exist.  The  record  must  be  created  with  the  information 
from  the  template.  The  cash  collection  amount  plus  the 
voucher  deduction  amount  plus  the  write-off  amount  must  not 
exceed  the  establishment  amount.  The  CD  amount  must  egual 
the  cash  collection  amount. 

Correction 

Corrections  are  made  to  either  dollar  data  elements, 
information  data  elements,  or  control  data  elements.  For 
the  correction  transaction,  the  accounts  receivable  record 
must  exist  and  be  changed  appropriately.  The  processing 
requirements  for  the  correction  of  dollar  data  elements  are 
basica  iiy  the  same  as  those  for  the  original  transaction, 
except  that,  in  all  cases,  the  amount  entered  on  the 
template  may  be  either  positive  or  negative.  Amounts  from 
the  accounts  receivable  record  must  be  increased  or  reduced. 
The  normal  processing  edits  must  be  satisfied;  in  addition, 
a negative  change  must  not  increase  the  CD  amount  above  0 
and  must  not  reduce  any  of  the  other  amounts  below  0.  For 
the  prior  year  reopening  process,  the  dollar  data  elements 
are  establishment  dollars,  cash  collection  dollars,  voucher 
deduction  dollars,  CD  dollars,  bad  check  dollars,  and  write- 
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off  dollars.  The  processing  requirement  for  the  correction 
of  information  data  elements  specifies  that  the  new  value  of 
the  element  be  overlaid  on  the  old.  The  information  data 
elements  are  the  Contract/Order  Number,  MA,  PY,  FS,  date  of 
bill,  account  symbol,  the  reimbursement  indicator,  the 
refund  indicator,  the  deposit  on  containers  indicator,  and 
the  extent  of  refund  indicator.  If  any  of  the  control  data 
elements  are  entered  incorrectly,  the  transaction  must  be 
reversed  and  a new  transaction  entered.  The  control  data 
elements  are  the  bill  number.  Trip  Number,  and 
Transportation  Bequest  Number. 


To  satisfy  audit  trail  requirements,  the  transaction 
information  must  be  recorded  in  a transaction  history. 
Initial  and  correction  transactions  must  be  identified  in 
the  transaction  history. 

Output  - Section  2.13.2  discusses  the  standard  online 
responses  and  error  messages  required  for  the  prior  year 
reopening  process. 


2.13.2  Output  Message  Requirements 

Figures  2.13-30  through  2.13-33  contain  a list  of 
output  message  requirements.  Figure  2.13-34  contains  a 
correlation  of  output  messages  by  transaction. 
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**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

TRAVEL 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

TRAVEL  - UPDATE 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

TRAVEL  - CORRECTION 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

COMMERCIAL 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

COMMERCIAL  - UPDATE 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

COMMERCIAL  - CORRECTION 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

PAYROLL 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

PAYROLL  - UPDATE 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

PAYROLL  - CORRECTION 

*♦** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

MISC  RECEIPT 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

MISC  RECEIPT  - 

UPDATE 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

MISC  RECEIPT  - 

CORRECTION 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

DEPOSIT  FUND 

**** 

A/R 

ESTABLISHMENT 

TRANSACTION 

- 

DEPOSIT  FUND  - 

UPDATE 

**** 

A/E 

ESTABLISHMENT 

TRANSACTION 

- 

DEPOSIT  FUND  - 

CORRECTION 

**** 

A/R 

LIQUIDATION  TRANSACTION  - 

CASH  COLLECTION 

**** 

A/R 

LIQUIDATION  TRANSACTION  - 

CASH  COLLECTION  - 

UPDATE 

**  ** 

A/R 

LIQUIDATION  TRANSACTION  - 

CASH  COLLECTION  - 

CORRECTION 

**** 

A/R 

LIQUIDATION  TRANSACTION  - 

VOUCHER  DEDUCTION 

♦ ♦★A 

A/R 

LIQUIDATION  TRANSACTION  - 

VOUCHER  DEDUCTION 

- UPDATE 

**** 

A/R 

LIQUIDATION  TRANSACTION  - 

VOUCHER  DEDUCTION 

- CORRECTION 

****  A/R  CERTIFICATE  OF  DEPOSIT  TRANSACTION 

*****  A/R  CERTIFICATE  OF  DEPOSIT  TRANSACTION  - UPDATE 

****  A/R  CERTIFICATE  OF  DEPOSIT  TRANSACTION  - CORRECTION 

****  TRAVEL  ADVANCE  CERTIFICATE  OF  DEPOSIT  TRANSACTION 

****  TRAVEL  ADVANCE  CERTIFICATE  OF  DEPOSIT  TRANSACTION  - UPDATE 

****  TRAVEL  ADVANCE  CERTIFICATE  OF  DEPOSIT  TRANSACTION  - CORRECTION 

****  A/R  BAD  CHECK  TRANSACTION 

****  A/R  BAD  CHECK  TRANSACTION  - UPDATE 

****  A/R  BAD  CHECK  TRANSACTION  - CORRECTION 

****  A/R  WRITE-OFF  TRANSACTION 

****  A/R  WRITE-OFF  TRANSACTION  - UPDATE 

****  A/R  WRITE-OFF  TRANSACTION  - CORRECTION 

****  DEPOSIT  FUND  PAYMENT  TRANSACTION 

****  DEPOSIT  FUND  PAYMENT  TRANSACTION  - UPDATE 

****  DEPOSIT  FUND  PAYMENT  TRANSACTION  ~ CORRECTION 


Figure  2.13-30.  - Accounts  Receivable  transaction-begun  messages. 
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****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - TRAVEL 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - TRAVEL  - UPDATE 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - TRAVEL  - CORRECTION 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - COMMERCIAL 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - COMMERCIAL  - UPDATE 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - COMMERCIAL  - CORRECTION 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - PAYROLL 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - PAYROLL  - UPDATE 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - PAYROLL  - CORRECTION 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - MISC  RECEIPT 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - MISC  RECEIPT  - UPDATE 

****  DEPOSIT  FUND  TRANSFER  TRANSACTION  - MISC  RECEIPT  - CORRECTION 

****  AIRCRAFT  SPARES  ESTABLISHMENT  TRANSACTION 

****  AIRCRAFT  SPARES  ESTABLISHMENT  TRANSACTION  - UPDATE 

****  AIRCRAFT  SPARES  ESTABLISHMENT  TRANSACTION  - CORRECTION 

****  AIRCRAFT  SPARES  CASH  COLLECTION  TRANSACTION 

****  AIRCRAFT  SPARES  CASH  COLLECTION  TRANSACTION  - UPDATE 

****  AIRCRAFT  SPARES  CASH  COLLECTION  TRANSACTION  - CORRECTION 

****  AIRCRAFT  SPARES  VOUCHER  DEDUCTION  TRANSACTION 

****  AIRCRAFT  SPARES  VOUCHER  DEDUCTION  TRANSACTION  - UPDATE 

****  AIRCRAFT  SPARES  VOUCHER  DEDUCTION  TRANSACTION  - CORRECTION 

****  A/R  PRIOR  YEAR  REOPENING  TRANSACTION 

****  a/r  PRIOR  YEAR  REOPENING  TRANSACTION  - UPDATE 

****  A/R  PRIOR  YEAR  REOPENING  TRANSACTION  - CORRECTION 

B0 1 0 TYPE  OF  TRANSACTION  NOT  SPECIFIED 

B o 1 1 MULTIPLE  TYPES  OF  TRANSACTIONS  SPECIFIED 

5062  BOTH  • UPDATE 1 AND  'CORRECTION'  MUST  NOT  BE  SPECIFIED 

BQ90  TYPE  OF  LIQUIDATION  NOT  SPECIFIED 

C360  TYPE  OF  RECEIVABLE  NOT  SPECIFIED 

C361  MULTIPLE  TYPES  OF  RECEIVABLE  SPECIFIED 


Figure  2.13-30.  - Accounts  Receivable  transaction-begun 
messages  (concluded)  . 


Code 


Message 


JV 000  TRANSACTION  COMPLETE 


Figure  2.13-31.  - Accounts  Receivable 
transaction-complete  messages. 
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Code  Message 

B 1 00  'AS  OF'  DATE  INVALID 

B 1 0 1 'AS  OF'  DATE  MUST  BE  PRIOR  TO  SYSTEM  DATE 

B 1 10  MA  NOT  ENTERED 

Bill  MA  INVALID 

B 1 1 4 MA  MUST  BE  REIMBURSABLE 

B115  MA  MUST  NOT  BE  97 

B 1 20  PY  NOT  ENTERED 

B121  PY  INVALID 

B 1 26  PY  MUST  BE  58  TO  CURRENT  FISCAL  YEAR 

B 1 30  FS  NOT  ENTERED 

B 1 39  FS  INVALID 

B 1 70  PWC  NOT  ENTERED 

B 17 1 PWC  INVALID 

B 174  PWC  MUST  BE  9 DIGITS 

B 1 90  OBJECT  CLASS  NOT  ENTERED 

B 191  OBJECT  CLASS  INVALID 

B 300  PURCHASE  REQUEST  NUMBER  NOT  ENTERED 

B301  PURCHASE  REQUEST  NUMBER  INVALID 

B 3 1 1 SUFFIX  INVALID 

B320  PERFORMING  ORGANIZATION  NOT  ENTERED 

B 3 21  PERFORMING  ORGANIZATION  INVALID 

B360  CONTRACT/ORDER  NUMBER  NOT  ENTERED 

B 36 1 CONTRACT/ORDER  NUMBER  INVALID 

B600  f AMOUNT  NOT  ENTERED 

B6 0 1 $ AMOUNT  INVALID 

B6 02  $ \ MOUNT  MUST  NOT  BE  ZERO 

B604  $ AMOUNT  MUST  BE  GREATER  THAN  ZERO 

B607  $ AMOUNT  MUST  BE  LESS  THAN  ZERO 

B930  VOUCHER  NUMBER  NOT  ENTERED 

B931  VOUCHER  NUMBER  INVALID 

B932  VOUCHER  NUMBER  MUST  BE  BLANK 

B940  CD  NUMBER  NOT  ENTERED 

B941  CD  NUMBER  INVALID 

B942  CD  NUMBER  MUST  BE  BLANK 


Figure  2.13-32.  - Accounts  Receivable  data  eleaent 
edit  error  messages. 
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Code 


Message 
C010  TRIP  NUMBER  INVALID 

C011  TRIP  NUMBER  MOST  BE  GREATER  THAN  ZERO 
C 0 1 2 TRIP  NUMBER  MUST  BE  BLANK 

C 020  TRANSPORTATION  REQUEST  NUMBER  NOT  ENTERED 

C021  TRANSPORTATION  REQUEST  NUMBER  INVALID 

C 022  TRANSPORTATION  REQUEST  NUMBER  MUST  BE  BLANK 

C 040  NAME  CODE  NOT  ENTERED 

CO  41  NAME  CODE  INVALID 

C100  BILL  NUMBER  NOT  ENTERED 

C101  BILL  NUMBER  INVALID 

C 1 02  BILL  NUMBER  MUST  BE  BLANK 

C110  DATE  OF  BILL  INVALID 

C 1 20  ACCOUNT  SYMBOL  NOT  ENTERED 

C 1 2 1 ACCOUNT  SYMBOL  INVALID 

Cl  30  ESTABLISHMENT  $ NOT  ENTERED 

C 1 31  ESTABLISHMENT  $ INVALID 

C 132  ESTABLISHMENT  $ MUST  NOT  BE  ZERO 

C 1 34  ESTABLISHMENT  $ MUST  BE  GREATER  THAN  ZERO 

C 1 40  CASH  COLLECTION  $ NOT  ENTERED 

C 1 41  CASH  COLLECTION  $ INVALID 

C 1 42  CASH  COLLECTION  $ MUST  NOT  BE  ZERO 

C144  CASH  COLLECTION  $ MUST  BE  GREATER  THAN  ZERO 

C 1 51  VOUCHER  DEDUCTION  $ INVALID 

C 1 52  VOUCHER  DEDUCTION  $ MUST  NOT  BE  ZERO 

C 1 54  VOUCHER  DEDUCTION  $ MUST  BE  GREATER  THAN  ZERO 

Cl  60  CD  $ NOT  ENTERED 

C 1 6 1 CD  $ INVALID 

C 1 62  CD  $ MUST  NOT  BE  ZERO 

C 1 64  CD  $ MUST  BE  GREATER  THAN  ZERO 

C 17 1 WRITE-OFF  $ INVALID 

C 1 72  WRITE-OFF  $ MUST  NOT  BE  ZERO 

C 1 74  WRITE-OFF  $ MUST  BE  GREATER  THAN  ZERO 

C 1 8 1 BAD  CHECK  $ INVALID 

C 1 82  BAD  CHECK  $ MUST  NOT  BE  ZERO 

C 1 84  BAD  CHECK  $ MUST  BE  GREATER  THAN  ZERO 


Figure  2-13-32.  - Accounts  Receivable  data  element 
edit  error  messages  (continued)  . 
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Cl 90  TYPE  OF  RECEIVABLE  NOT  SPECIFIED 
C191  MULTIPLE  TYPES  OF  RECEIVABLE  SPECIFIED 
C195  EXTENT  OF  REFUND  NOT  ENTERED 

C 1 96  BOTH  PARTIAL  AND  COMPLETE  REFUND  MUST  NOT  BE  ENTERED 
C 1 97  EXTENT  OF  REFUND  MUST  BE  BLANK 

C370  BOTH  'DEPOSIT  ON  CONTAINERS'  AND  • REIM BURSEMENT'  MUST  NOT  BE  SPECIFIED 
C371  BOTH  'REIMBURSEMENT'  AND  'REFUND'  MUST  NOT  BE  SPECIFIED 

C50B  PY , FS , PWC  COMBINATION  INVALID 

C520  FS,  ACCOUNT  SYMBOL  COMBINATION  INVALID 

C521  FS  , ACCOUNT  SYMBOL  COMBINATION  INVALID 


Figure  2- 13-32.  - Accounts  Receivable  data  eleaent 
edit  error  messages  {concluded) . 
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D 1 42  PWA  ISSUES  INSUFFICIENT 

MA PY FS BO PWC 

OBJECT  CLASS CARRIER  ID SUB  ID 

ISSUES  $_, , , . UPDATE  , ■ — ~ 

D 1 43  PWA  BALANCE  INSUFFICIENT  TO  INCREASE  ISSUES 

BA  PY FS  RO  PWC 

OBJECT  CLASS  CARRIER  ID  SUB  ID  

BALANCE  , , . UPDATE  $_, , , ■ — " 

D180  PERFORMANCE  DATA  RECORD  NOT  FOUND 

PURCHASE  REQUEST  NO.  SUFFIX  

Cl 86  PERFORMANCE  DATA  RECORD  CLOSED 

PURCHASE  REQUEST  NO.  SUFFIX  

D 1 92  CONTRACT  RECORD  NOT  FOUND 

CONTRACT/ORDER  NO.  

D 1 97  CONTRACT  RECORD  CLOSED 

CONTRACT/ORDER  NO.  

D200  TRAVEL  PERFORMANCE  DATA  RECORD  NOT  FOUND 

TRAVEL  AUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY  

TRIP  NO.  TRANS  REQUEST  NO.  

D204  TRAVEL  PERFORMANCE  DATA  RECORD  CLOSED 

TRAVEL  AUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY  

TRIP  NO.  TRANS  REQUEST  NO.  

D205  C/O/C  $ MUST  NOT  BE  LESS  THAN  ZERO 

TRAVEL  AUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY  

TRIP  NO.  TRANS  REQUEST  NO.  

C/O/C  , , • UPDATE  i_. , , • — ~ 

D206  DISBURSEMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 

TRAVEL  AUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY  

TRIP  NO.  TRANS  REQUEST  NO.  

DISBURSEMENT  , r • UPDATE  , , ■ — “ 

D220  TRAVEL  ADVANCE  CONTROL  RECORD  NOT  FOUND 
CD  NO.  CD  

D221  TRAVEL  ADVANCE  CONTROL  RECORD  CLOSED 
CD  NO.  CD  

D222  CD  $ EXCEED  CASH  COLLECTION  $ 

CD  NO.  CD  

CD  . . UPDATE  $., , , -__± 

Figure  2.13-33.  - Accounts  Receivable  processing  error  messages. 
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CASH  COLLECTION  , # • UPDATE  , .# 

0223  CD  $ MOST  NOT  BE  GREATER  THAN  ZERO 
CD  NO.  CD  

CD  , , , • “ UPDATE  $_# t • — 

D3 06  COMMITMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 

PURCHASE  REQUEST  NO.  SUFFIX  

COMMITMENT  $_, , , . UPDATE  » r 

D3 07  OBLIGATION  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDEF  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO. SUFFIX  __ 

OBLIGATION  , , - UPDATE  , /_ — 

D 3 08  COST  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

COST  $_, 0 0 • UPDATE  , , • — - 

D3 09  DISBURSEMENT  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

DISBURSEMENT  , r * UPDATE  , # 

D312  DEPOSIT  ON  CONTAINERS  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDEE  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

DEPOSIT  , , . UPDATE  # # * — * 

D31 4 ADVANCE  ESTABLISHED  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

ADVANCE  , • UPDATE  , , • — " 

D315  ADVANCE  LIQUIDATED  $ MUST  NOT  BE  LESS  THAN  ZERO 

CONTRACT/ORDER  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

ADVANCE  , , . UPDATE  , / ■ — * 

D330  LETTER  OF  CREDIT  CONTROL  RECORD  NOT  FOUND 

LETTER  OF  CREDIT  NO.  

D332  LETTER  OF  CREDIT  ISSUANCE  RECORD  NOT  FOUND 

LETTER  OF  CREDIT  NO. PI  „ 

0334  LETTER  OF  CREDIT  WITHDRAWAL  RECORD  NOT  FOUND 

Figure  2.13-33.  - Accounts  Receivable  processing 
error  messages  (continued) • 


2.13-131 


Message 


Code 

LETTER  OF  CREDIT  NO.  PY  

D 3 42  ISSUANCE  $ MUST  NOT  BE  LESS  THAN  ZERO 

LETTER  OF  CREDIT  NO. PY  

CONTRACT/GRANT  NO.  SCHEDULE 

PURCHASE  REQUEST  NO.  SUFFIX  

ISSUANCE  , , . UPDATE  , , . - 

D343  WITHDRAWAL  $ BUST  NOT  BE  LESS  THAN  2EBO 

CONTRACT/GRANT  NO.  SCHEDULE  _ 

PURCHASE  REQUEST  NO.  SUFFIX  

LETTER  OF  CREDIT  NO. PY  

WITHDRAWAL  $_, , , . UPDATE  $_, , , ._ 

D500  ACCOUNTS  RECEIVABLE  RECORD  NOT  FOUND 

BILL  NO.  - TRIP  NO.  TRANS  REQUEST  NO. 

D501  ACCOUNTS  RECEIVABLE  RECORD  CLOSED 

BILL  NO.  - TRIP  NO.  TRANS  REQUEST  NO. 

D502  ACCOUNTS  RECEIVABLE  RECORD  ALREADY  EXISTS 

BILL  NO.  - TRIP  NO. TRANS  REQUEST  NO. 

D510  CASH  COLLECTION  $ + VOUCHER  DEDUCTION  $ + 

WRITE-OFF  $ EXCEED  ESTABLISHMENT  $ 

BILL  NO.  - TRIP  NO. TRANS  REQUEST  NO. 

CASH  COLLECTION  , UPDATE  , , 

VOUCHER  DEDUCTION  $_, , . UPDATE  , 

WRITE-OFF  $_, , . UPDATE  $_, , , 

ESTABLISHMENT  , . UPDATE  , , 

D5 11  CD  $ EXCEED  CASH  COLLECTION  S 

BILL  NO.  - TRIP  NO.  TRANS  REQUEST  NO. 

CD  $ r » t . UPDATE  $ it  § i . — 

CASH  COLLECTION  , , . UPDATE  $_, , , 

D520  ESTABLISHMENT  $ BUST  NOT  BE  LESS  THAN  ZERO 

BILL  NO.  - TRIP  NO.  TRANS  REQUEST  NO. 

ESTABLISHMENT  $_, , , . UPDATE  $_. , , 

D521  CASH  COLLECTION  $ MUST  NOT  BE  LESS  THAN  ZERO 

BILL  NO.  - TRIP  NO. TRANS  REQUEST  NO. 

CASH  COLLECTION  , . UPDATE  , , 

D522  VOUCHER  DEDUCTION  $ MUST  NOT  BE  LESS  THAN  ZERO 

BILL  NO. - TRIP  NO.  TRANS  REQUEST  NO. 

Figure  2.13-33.  - Accounts  Receivable  processing 
error  messages  (continued) . 
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VOUCHER  DEDUCTION  , , . UPDATE  , , 

D523  CD  $ MUST  NOT  BE  GREATER  THAN  ZERO 

BIEL  NO.  - TRIP  NO.  TRANS  REQUEST  NO. 

CD  S_, , , . - UPDATE  , , . 

D524  BAD  CHECK  $ MUST  NOT  BE  LESS  THAN  ZERO 

BILL  NO.  - TRIP  NO.  TRANS  REQUEST  NO.  

BAD  CHECK  $_, , , . UPDATE  $_, , , . - 

D525  WRITE-OFF  $ MUST  NOT  BE  LESS  THAN  ZERO 

BILL  NO.  - TRIP  NO.  TRANS  REQUEST  NO.  

WRITE-OFF  , , . UPDATE  , , . - 

D530  ESTABLISHMENT  $ EXCEED  DISBURSEMENT  $ 

CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

ESTABLISHMENT  $_, , , . UPDATE  , , . ± 

DISBURSEMENT  $_, , , . UPDATE  $_, , , . ± 

D531  ESTABLISHMENT  $ EXCEED  DISBURSEMENT  $ 

TRAVEL  RUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY 

TRIP  NO,  TRANS  REQUEST  NO.  

ESTABLISHMENT  S_, , , UPDATE  , , . ± 

DISBURSEMENT  , . UPDATE  $_, , , . ± 

D532  MA  NOT  REIMBURSABLE  FOR  REIMBURSEMENT 

PURCHASE  REQUEST  NO.  SUFFIX  MA 

D533  MA  NOT  REIMBURSABLE  FOR  REIMBURSEMENT 

TRAVEL  AUTH  NC.  TYPE  OF  TRAVEL  ACTIVITY 

TRIP  NO. TRANS  REQUEST  NO. MA 

D530  ESTABLISHMENT  $ EXCEED  DEPOSIT  ON  CONTAINERS  $ 

CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

ESTABLISHMENT  , , . UPDATE  , , . ± 

DEPOSIT  , , . UPDATE  , , . ± 

D535  ESTABLISHMENT  $ EXCEED  PAYMENT  ON  REIMBURSABLE  ORDERS  * 
CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

ESTABLISHMENT  , , . UPDATE  , • ± 

PAYMENT  $_, , , . UPDATE  , » . ± 

D536  ESTABLISHMENT  S EXCEED  ADVANCE  ESTABLISHED  4 

Figure  2.13-33.  - Accounts  Receivable  processing 
error  nessages  (continued) . 
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CONTR ACT/O RDEB  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

ESTABLISHMENT  , , , . UPDATE  , , . ± 

ADVANCE  V, r , - UPDATE  , , . ± 

D 537  ESTABLISHMENT  $ EXCEED  WITHDRAWAL  $ 

CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

ESTABLISHMENT  $_, , , . UPDATE  , , . ± 

WITHDRAWAL  $_, . UPDATE  , , . ± 

D 540  MA , PY , OBJECT  CLASS  , PWC  , AND 

PERFORMING  ORGANIZATION  COMBINATION  NOT  DEFINED 

D 5 4 1 PY , ACCOUNT  SYMBOL COMBINATION  NOT  DEFINED 

D 550  CASH  COLLECTION  $ + VOUCHER  DEDUCTION  $ + 

WRITE-OFF  $ EXCEED  ESTABLISHMENT  $ 

CONTRACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

CASH  COLLECTION  $_  , , , . UPDATE  , , ± 

VOUCHER  DEDUCTION  , , . UPDATE  , . ± 

WRITE-OFF  , . UPDATE  , k_, . ± 

ESTABLISHMENT  $_, , , . UPDATE  $_, , , . ± 

D551  CASH  COLLECTION  $ + VOUCHER  DEDUCTION  $ + 

WRITE-OFF  $ EXCEED  ESTABLISHMENT  $ 

TRAVEL  AUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY 

TRIP  NO.  TRANS  REQUEST  NO.  

CASH  COLLECTION  , , . UPDATE  , , . ± 

VOUCHER  DEDUCTION  gmmi , . UPDATE  r , . ± 

WRITE-OFF  , r . UPDATE  , , . ± 

ESTABLISHMENT  f , UPDATE  , , . ± 


Figure  2.13-33.  - Accounts  Receivable  processing 
error  messages  (continued) . 
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D552  CD  $ EXCEED  CASH  COLLECTION  $ 

CONTBACT/ORDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

CD  , , UPDATE  , , -__± 

CASH  COLLECTION  > , • UPDATE  $_, > », 

D553  CD  $ EXCEED  CASH  COLLECTION  $ 

TRAVEL  AUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY  

TRIP  NO.  TRANS  REQUEST  NO.  

CD  , UPDATE  , r -__± 

CASH  COLLECTION  t » • UPDATE  . # 

D554  PAYMENT  * EXCEED  CD  $ 

BILL  NO.  ^ 

PURCHASE  REQUEST  NO.  SUFFIX  

PAYMENT  $_, , , • UPDATE  $_, , , • — ± 

CD  $_, , , UPDATE  , , -__i 

D555  PAYMENT  *1  MUST  NOT  BE  LESS  THAN  ZERO 
BILL  NO.  - 

PURCHASE  REQUEST  NO.  SUFFIX  

PAYMENT  $_, , , . UPDATE  $_, , / • — “ 

D560  TRANSFER  $ NOT  EQUAL  ESTABLISHMENT  $ 

BILL  NO.  

TRANSFER  , . . ESTABLISHMENT  , , 

D561  TRANSFER  $ EXCEED  CASH  COLLECTION  $ OR  CD  $ 
CONTRACT/CRDER  NO.  

PURCHASE  REQUEST  NO.  SUFFIX  

TRANSFER  , # • CASH  COLLECTION  > — 

CD  $ # t _____  t • — 

D562  TRANSFER  $ EXCEED  CASH  COLLECTION  $ OR  CD  $ 

TRAVEL  AUTH  NO.  TYPE  OF  TRAVEL  ACTIVITY  

TRIP  NO.  TRANS  REQUEST  NO. 

TRANSFER  S_, , , • CASH  COLLECTION  

CD  $ m„  * ^ UTr.r  0 # ■ 

D563  ESTABLISHMENT  $ NOT  EQUAL  ZERO 

BILL  NO. ESTABLISHMENT  r r • — 


Figure  2.13-33.  - Accounts  Receivable  processing 
error  messages  (concluded)  . 


2. 13-135 


Message 


Transaction 


abbbbbbbbbbbbbeebbbbb 
001111111111111133333 
060011  1 12227779900122 

020  10  1 4501  60  1 401  0 1 10  1 


Establishment 
Travel  initial 

Opdate/Correction 

CcBmercial  initial 
Update/Ca erection 

Payroll  initial 
Urdate/Correction 


Transaction 

Establishment 
Travel  initial 

Update/Correction 

Commercial  initial 
Update/Correction 

Payroll  initial 

Opdate/Correction 

Miscellaneous  receipt  initial 
Update/Correction 

Deposit  fund  initial 
Update/Correction 


XXX 

XXX 


X xxxx  xxxxxxxxxx 
xxxxxxxxxxxxxxxx 


X X 
X X 


Miscellaneous  receipt  initial  X XX 

Update/Correction  X X X X 

Deposit  fund  initial  x XX 

Update/Correction  X X X X 


BBBBCCCCCCCCCCCCCCCCC 

6666000000001  1 1 1 133  3 5 
00001  1 122244G0  1226670 
012401201201010010100 


XX  XXX 

XXX  XX 


X X 
XXX 


XX  X 
XXX 


X X X X 

X X X X 


Transaction 

Establishment 
Travel  initial 

Opdate/Correction 

Commercial  initial  X 

Opdate/Correction  X 

Payroll  initial 

Opdate/Correction  X 

Miscellaneous  receipt  initial 
Update/Correction  X 

Deposit  fund  initial 

Update/Correction  X 


ODDDDD  DDDD  DDDOEDDD 
111122555555555555 
889900000123  3 33333 

0627  0 4 0 1 2 00Q  1 2 3 456 


D D D D D 
5 5 5 5 5 
3 4 4 5 5 
7 0 10  1 


figure  2.13-34 


- Accounts  heceivable  messages  by  transaction. 


& £ 

<0 

£*  Gy 


Transaction 

Liquidation 
Cash  collection 
Update/Correction 

Voucher  deduction 
Update/Correction 


Transaction 

Liquidation 
Cash  collection 
Ul date/Correction 

Voucher  deduction 
Update/Correction 


0 0 0 0 

0 6 9 9 

0 2 0 1 


X X 

XXX 


BBBBBBB3BE33CC 

11666699S9  3 9C3 
0000003334491  1 
01012401201201 


X X X X 

X X X X X 


X X X X 

X X X X 


CCCDDODDD 
01111112  2 
2 0 0 8 8 9 9 0 0 
1 0 1 0 6 2 7 0 4 


X x 
X X 


X X 
X X 


XXX 

XXX 


X X 
X X 


XXX 

XXX 


XXX 
X X 


3 0 D D 
5 5 5 5 
0 0 11 
0 10  1 


XXX 
X X X X 


D D D D 
5 5 5 5 
2 2 55 
12  0 1 


X X 
X X 


X X 
X X 


XXX 
X X T 


X X X X 

X X X X 


C D 
5 5 
5 5 
2 3 


Message  A 
0 
0 

Transaction  ^ 

Ce£tificaie_of-de£Osit 

Travel  X 

Update/Correction  X 

Commercial  X 

Update/Correction  X 

Payroll  X 

Update/Correction  X 

Deposit  fund  or  niscellane ous  receipt  X 
Update/Correction  X 


E 5 B B 
16  6 6 
0 0 0 0 
10  12 


bsbcccccccc 

699C00C0r  1 1 

044  1 1 122200 

4 0 10  12  0 12  0 1 


D 0 D D D 
11111 
4 4 8 8 9 
2 3 0 6 2 


Message 


Transaction 

S££titica.ie,gf  _fle posit 
Travel 

Update/Correction 

Coar^rcial 

Update/Correction 

Payroll 

gp date/Correction 

Deposit  fund  or  niscellaneous  receipt 
Update/Correction 


0 3 u f>  3 D 

1 2 2 2 2 3 
9 0 0 3 0 0 
7 0 4 5 6 6 


b D D t C 1 P 

3 5 5 5 5 5 5 

4 0 112  5 5 

3*1  1323 


r 

V* 


Figure  2.13-34.  - Accounts  fectivable  aesSiles  tv  »unsic*-nn  (ccrtir . 


Message 


A 

a 
o 

Transaction  ^ 

Travel  advance  certificate  of  deposit 

Travel  advance  certificate  of  deposit  X 

Update/Correction  +■ 


BBBBB3BBBDDDD 

01  16666992222 
6GQ0000442222 
2010124010  123 


X X X X XXX  XX  X 

xxxxxx  xxxxxx 


Transaction 


Message  A B B *J  B B 

0 0 0 0 1 1 

0 116  0 0 

0 0 1 2 0 1 


bbbbbbbbb 
666699999 
000033344 
0 1 2 4 0 1 2 0 1 


bccccccddb 
9000011111 
9 1 1 2 2 0 0 446 
2 C 1 0 1 C 1 2 3 0 


Rftd  check  or_vritg^6ff 
Initial 

Update/Correction 


XXX 

XXX 


X X X X X X X X x 

a X X X x X X X X 


X X X X X X X 

x X X X X X X 


X 

X 


X 

X X 


7 

X 


Transaction 


Message  ODD 
1 1 1 
8 9 9 

6 2 7 


D D V D D D 
2 2 2 2 3 3 
0 0 0 0 0 0 
0 4 5 6 6 7 


D D D t)  D D 
3 3 3 6 5 5 
ooiooi 

8 9 2 0 1 0 


D I D D D D 
5 5 5 5 5 5 
2 2 2 2 5 5 
13  4 5 0 1 


gad  check  or  write-off 
Initial 

Update/Correction 


X X X X X 

xxxxxx 


X X X X X 


X X 

X x 


XXX  XX 

X X X X X X X 


Transaction 


Message 


A B 8 B B B 
0 0 116  6 
0 6 0 0 0 0 
0 2 0 10  1 


B B B B C C D 

6 6 9 9 1 1 1 

0 0 3 3 0 0 8 

2 4 0 1 0 1 0 


D C D 0 D 
1 5 5 5 c 
8 0 0 5 5 
6 0 14  5 


Deposit  fund_paxBgflt 
Initial 

Update/Correct  ton 


X X X X X 

XXXXXX 


X X X X X 

X X X X X 


X X X X X 

xxxxxx 


pLjur*  2.13-3U.  - Accounts  EecoiMble  «essiS«s  t?  transaction  (continued). 


sn-n 


Hessage 


Transaction 


ABBBBBBBBBBBBBS  B BB 
001111111111111333 
06001  11  1227  7 799001 
020101450101*1010  11 


Deposit  fond  transfer 

Initial^  X XXXXXXXXXXXXXXIX 

Update/Correction  XX  X XXXXXXXX  XXXXXXX 

Be  ssage  B BBBC  CCCCCC  CCCCCCD 

‘ 66  6 600000011113351 

00001  1 224400226708 

Transaction  01  4701010101010080 


Deposit  fund  transfe r 
Initial  XXX 

Update/Correction  X X 


xxxxxxxxxxxxxx 
xxxxx  xxxxxxxxx 


DDDDDDDDDD  DBDDDDDD 

1 12255555555555555 
990000033333333446 

2 7 040  1 201  2 34567010 


Deposit  fund  transfer 
Initial 

Updatfc /Correction 


XXX  XXXXXXXXXXXXXXX 
X X 7 X X X XX 


Establishment 

Update/Correction 

Cash  Collection 

Update/Correction 

Voucher  deduction 
Update/Correction 


Aircraft  spares 
Establishment 

Update/Correction 

Cash  collection 

Update/Correction 

"oucher  decuction 
Update/Correction 


ABBBBB8BBBBBBEBBC 
00001133366669  9 91 
011600001000  0 3310 
001201  0 1101240120 


CCDDDDDDDDDDDDCDD 
11  1 1 1 I 3 33355555rr 

00  4 4 88  0 00  0 0 0 1 2222 

12230667890  1 00  1 21 


Figure  2-13-34.  - Accounts  Receivable  messages  by  transaction  {continued}. 


13-140 


lessage 


Transaction 


ABB 
0 1 1 
0 0 0 
0 0 1 


B B B B B B 
1 11  1 1 1 
1 2 2 2 3 3 
5 0 1 6 0 9 


EBB 
3 3 3 

0 0 1 

Oil 


BECCCCCCCCCCCCCCCC 
3300001  11  1111  11111 
331122001223333444 
0101010  1 0010124012 


Reopening 

Initial 

Correction 


Transaction 


Hessage 


cccccccccccccc 
11111111111111 
4555666  6 777888 
412  4 0 124124124 


c c c c c 
11111 
9 9 9 9 9 
0 15  6 7 


C C C C 
3 3 5 5 
7 7 2 2 
0 10  1 


C 0 
5 5 
0 0 
1 2 


D D D D D D 
5 5 5 5 5 5 
2 2 2 2 2 2 
0 1 2 3 4 5 


Reopening 

Initial 

Correction 


Figure  2.13-34.  - Accounts  Receivable  messages  by  transaction  (concluded) 


2.13.3  Inquiry  Requirements 


Figure  2.13-35  contains  a list  of  inquiry  input  data 
elements  and  response  data  elements  required  for  the 
accounts  receivable  process. 

2.13.4  Report  Requirements 

Section  2.19.5  lists  the  accounts  receivable  report 
requirements.  The  following  reports  are  included: 

• Open  Accounts  Receivable  Status 

• Closed  Accounts  Receivable  Status 

• Accounts  Receivable  Aging  Report 

• Reimbursable  Order  Status  Report 

A list  of  valid  daily  transactions  must  appear  in  the 
Daily  Transaction  List  Accounts  Receivable  Section  report 
described  in  section  2.19.7. 


2. 13-141 


ztu-ei 


Inquiry  description 


Input  data  elements 


Timing 


Response  data  elements 


to 


Contract/Order  status  Item 


Purchase  Reguest  status  Item 


Contract/Order  Humber  Immediate 


Purchase  Reguest  Number  Immediate 
Suffix  [where  other 
than  base  Suffix 
status  required) 


Contract/Order  Number 

Last  contract  Schedule  Number 

Last  contract  Amendment  Number 

Contractor  name  code 

Contract  Obligation 

Contract  Cost 

Contract  Disbursement 

Contract  deposit  on  containers 

Contract  payment  by  others 

Contract  payment  on  reimbursable  orders 

Contract  discount 

Contract  withholding 

Contract  cancelled  check 

Contract  advance  established 

Contract  advance  liquidated 

Letter  of  credit  number 

Contract  issuance 

Contract  withdrawal 

Contract  accounts  receivable  established 
Contract  accounts  receivable  cash  collection 
Contract  accounts  receivable  voucher  deduction 
Contract  accounts  receivable  certificate 
of  deposit 

Contract  accounts  receivable  bad  check 
Contract  accounts  receivable  write-off 


Purchase  Reguest  Number 
Suffix 

flethod  of  Authority 
Program  Year 
Fund  Source 

Primary  Work  Code  {nine  digits) 

Responsible  Organization 
Object  Class 
Performing  Organization 
Primary  Job  Code 
Secondary  Job  Code 
Contract/Order  Humber 
Contract  Schedule  Number 
Amendment  Number 
Contractor  name  code 
Commitment 
Obligation 
Cost 

Disbursement 
Deposit  on  containers 
Payment  by  others 
Discount 
Withholding 
Cancelled  check 
Advance  established 
Advance  liquidated 
Issuance 
Withdrawal 

Accounts  receivable  established 
Accounts  receivable  cash  collection 
Accounts  receivable  voucher  deduction 
Accounts  receivable  certificate  of  deposit 
Accounts  receivable  bad  check 
Accounts  receivable  write-off 


Figure  2.13-35.  - Accounts  Receivable  inquiry  requirements 


inquiry  description 
Accounts  Receivable  status 


Name  code  status 


A'-  * 


A 

y 


Input  data  elements  Timing 


Response  data  elements 


Summary  Bill  Number  Same  day 

Trip  Number 

''’Transportation  Eeguest 
Number 


Summary  Name  code 


Same  day 


Bill  Number 
Trip  Number 

Transportation  Request  Number 
Date  or  bill 
Name  code 

Method  of  Authority 
Program  Year 
Fund  Source 
Account  symbol 
Contract/Order  Number 
Purchase  Request  Humber 
Suffix 

Reimbursement  indicator 
Deposit  on  containers  indicator 
Partial  or  complete  refund  indicator 
Accounts  receivable  established 
Accounts  receivable  cash  collection 
Accounts  receivable  voucher  deduction 
Accounts  receivable  certificate  of  deposit 
Accounts  receivable  bad  check 
Accounts  receivable  write-off 


Accounts 

Accounts 

Accounts 

Accounts 

Accounts 

Accounts 


receivable  established 
receivable  cash  collection 
receivable  voucher  deduction 
receivable  certificate  of  deposit 
receivable  bad  check 
receivable  write-off 


Figure  2.13-35.  - Accounts  Receivable  inquiry  requirements  (concluded) 


